SYSTEM AND METHOD OF ADMINISTERING, TRACKING AND 
MANAGING OF CLAIMS PROCESSING 

Inventors: Anthony Aquila, Ed Shrenk, Patrick Cole, Thomas Lyons, David Griffin, Mike 

Marsh, Christian Hassold, Fred Fisher 

I. Reference to Related Application 

This application claims priority under 35 U.S.C. § 119 (e) to U.S. Provisional 
Application Serial No. 60/194,128 filed April 3, 2000, by Anthony Aquila, which is 
incorporated herein by reference in its entirety. 

II. Background 

1 . Field of the Invention 

The present invention relates to insurance claim processing systems in general, 
and more particularly to administering, tracking and managing insurance claim 
processing systems. 

2. Description of the Background Art 

Processing, tracking and releasing funds for claims made upon insurance policies 
and similar risk shifting mechanisms has traditionally been a time intensive and resource 
intensive process. Traditionally, there are six major steps involved in the processing of 
claims: initial claims processing, loss appraisal, claims adjusting, satisfying the claim, 
settlement and payment, and management and analysis. 

Initial claims processing includes receiving initial claim data associated with a 
newly asserted claim, initial assessment of damages and tasks required to fulfill the 
claim, and assignment of those tasks to appropriate service providers. 

The claims process starts with the notification by the insured or claimant that an 
accident has occurred. Currently, this notification is typically completed by phone to the 
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carrier's first report unit or to an agent. The carrier then verifies policy coverage, creates 
a claim file and assigns the claim to an adjuster and an appraisal resource or directly to a 
service provider. Generally, the client must exchange several phone calls with the various 
commercial participants to schedule a damage estimate, select a repair facility and make 
car rental arrangements, if applicable. In addition, these processes are paper intensive 
because legacy claims systems do not support imaging and relevant documents such as 
estimates, photos, police reports and tow bills that arrive regularly by fax and mail 
throughout the life of the claim file. 

Automated initial claim capture systems are known. However, while relieving 
some of the burden on an insurance carrier's resources, traditional automated initial claim 
capture systems are not flexible. Claimants are forced through standardized questions in 
standardized formats that often do not fit well with their needs. Also, these systems are 
not configurable to use by a commercial participant or a claimant, nor do they are unable 
to fully facilitate the capture of supplemental information in addition to initial claim data 
and can thus be inaccurate. Moreover, initial claim capture systems usually connect 
directly to an insurance company's proprietary software or interface. An agent who deals 
with multiple insurance companies may need multiple systems or pieces of software. 

Initial claim processing also involves determining the importance of a given 
claim, in what order it should be addressed, what tasks need to be fulfilled to address the 
claims and what specific parties those tasks should be assigned to. Traditionally, a 
claims adjuster, who must fulfill each of these steps, handles this process. The process is 
labor intensive, requires a fair amount of familiarity with the situations similar to the one 
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at hand, and can be subjective, the combination of which results in expense to the 
insurance company, potential error and inconsistencies. 

Loss appraisal involves loss assessment and related activities. In most automobile 
insurance claims, the damage assessment is developed using computerized damage 
estimating software. However, conventional computerized estimating platforms utilize 
incompatible proprietary data and communications formats. Most carriers lack the ability 
to electronically integrate data from multiple systems, and therefore encourage or require 
their affiliated repair facilities members to use a specific estimating platform so that the 
data generated can be analyzed and compared to the results of other estimating resources 
used by an insurance carrier. In order to communicate with different carriers, repair 
facilities must often purchase multiple estimating and photo-imaging systems, creating 
redundant costs and expenses and lost time from having to re-enter data into different 
proprietary systems. 

Claims adjusting involves determining the fair claim settlement amount. Claims 
adjusting includes investigating the facts related to the claim and negotiating the cost of 
services to fulfill the claim with other commercial participants and/or settlement 
negotiations with the client. Traditionally, this process is handled by a claim adjuster, 
and requires data from a wide and disparate variety of internal and external sources, 
including computerized and paper-based systems. This problem causes frequent delays 
as key participants cannot be reached and as required documents are mailed or sent by 
expensive overnight delivery services. 

Satisfying the claim involves completing the services that are required to 
recompense the loss. The traditional process involves a variety of delays while service 
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providers await approval of adjusters for initial and supplemental costs. During the 
typical process, the consumer or suppliers to the service provider contacts the carrier or 
the service provider numerous times by phone. These calls disrupt the normal flow of 
work for the recipients and add costs and delays to the process. In addition, 
administrative overhead for repair facilities is high as they must rely on phone and fax to 
communicate with insurers, suppliers, and consumers. 

Settlement and payment involves delivery of the repaired vehicle in the case of 
repairable damage and payments either directly to the insured or to service providers. In 
the traditional process, carriers are required to produce multiple checks to a variety of 
service providers based on manual invoicing methods. Service providers may have to 
provide their services to the consumer before receiving payment for the work from the 
carriers and must wait extended periods for final payment. The movement, tracking of 
numerous payments, often in the form of checks, and the delays commonly involved, are 
additional problems faced in claims processing. 

Management and analysis involves management oversight of the process by 
commercial participants. Analysis of settlement cycle times, repair costs, revenue, 
margins, and consumer satisfaction are just a few examples of the business metrics 
utilized by the Commercial Participants. Gathering and processing of sufficient claim 
related data such as customer surveys traditionally requires a great amount of resources in 
the form of time and staff to track down answers, data, and analyze what is gathered. 
Data gathering traditionally yields a small amount of data making analysis less accurate, 
and any analysis that is conducted is usually on aging or outdated information. 
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As each of these processes presents difficulties, complexities to systems and 
processes which seek to address them, the combination of these processes, each of which 
needs to be addressed in claims processing, provides even deeper inefficiencies that have 
yet to be adequately addressed. Traditional claim management systems are each focused 
on a single or a few of these steps involved in processing claims, and often require the 
redundant re-collection, re-entry or re-formatting of collected information and data to 
cater to the specific needs of each of the processes involved. For a paper based claim file 
management system, information is limited to the number of physical copies of the 
material available, which are static and costly to move and store. In addition, bottlenecks 
are created when files are kept, for example by a claims adjuster who cannot be reached. 
For electronic claim management systems, proprietary systems, formats and 
communication methods similarly require redundant effort in the need to re-enter or 
reformat data to cater to each system involved in the process. Traditionally, there does 
not exist a centralized claim processing or storage system. Traditionally, claims 
processing is people intensive, requiring human involvement for phone calls, data 
collection and data entry, often requiring several days, and considerable inconvenience to 
the client while adding significantly to the insurance carrier's costs of adjusting the losses 
under claims. 

Accordingly, there is a need for an automated system for administering, tracking 
and managing claims processing. 
III. Summary of the Invention 

The present invention provides a centralized system and methods of 
administering, tracking and managing claims processing. More particularly, the system 
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and method processes, tracks and releases funds for claims made upon insurance policies 
and similar risk shifting mechanisms including but not limited to self insurance, 
indemnity provisions and surety and performance bonds. The invention is composed of 
sub-systems that can operate on a standalone basis or in conjunction with one or more 
sub-systems of the invention. The sub-systems include: 

The user interface and claim management sub-system (Deskview) allows a user to 
access, view, add, and edit claim data. Deskview also serves as a portal point to other 
sub-systems. 

The first notice of loss sub-system (FNOL) captures initial claim data directly 
from a consumer using client software. In another embodiment, FNOL captures initial 
claim data through a commercial participant. FNOL presents the user, the consumer of 
the commercial participant, with tailored questions, where the presentation format varies 
depending on the type of user. Also questions subsequent to certain gateway questions 
presented to the user vary according to the user's answers to the gateway questions. The 
claim data captured can be transmitted to and stored in the eclaim database, or insurance 
carrier system. 

The triage sub-system receives claim data and determines the severity and priority 
of the claim according to business rules established by an insurance carrier. Next, the 
triage sub-system determines the type or type(s) of assignees to assign a claim to 
according to business rules established by an insurance carrier. 

The assignment sub-system receives the claim from the triage sub-system, 
identifies the assignee most qualified for the assignment according to insurance carrier 
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business rules, makes the assignment, records that the assignment has been made, and 
notifies the assignee. 

The vendor connection and assignment management system (Connection) does 
not reside on the application layer, but is stored and operates on the vendor's I/O device 
1 ? and serves as a communication and management system for vendors, particularly 
service providers such as repair facilities and independent adjusters. In one embodiment, 
Connection resides and operates on internal system. 

The audit sub-system applies insurance carrier specific business rules, 
government regulations, and comprehensive trending analysis to detect and rectify any 
inconsistencies and irregular processing of claims, by auditing internal processes or user 
or service providers submitted data. 

The automated payment system (APS) automates the process of fulfilling 
payments required to fulfill an asserted claim. 

The customer satisfaction index collection sub-system (CSI sub-system) 
automates the gathering of satisfaction data from a policyholder or consumer to generate 
a Customer Satisfaction Index (CSI) for the service providers. 

The reporting sub-system summarizes and formats data stored eclaim file or the 
insurance carrier system based on a number of criteria to generate various reports. 
IV. Brief Description of the Drawings 

FIG. 1 is a block diagram of physical communication components and system 
architecture of a system of administering, tracking and managing insurance claim 
processing according to the invention; 



7 



22606/05796/DOCS/1159542.4 



FIG. 2 is a block diagram of logical components that components of a system of 
administering, tracking and managing insurance claim processing; 

FIG. 3 is a block diagram of a data flow relationship between participants and 
sub-systems of a system of administering, tracking and managing insurance claim 
processing; 

FIG. 4 is a flow diagram of a process of administering, tracking and managing 
insurance claim processing; 

FIG. 5 A is a flow diagram of the process of capturing initial claim data; 

FIG. 5B a flow diagram of a commercial participant's process of capturing initial 
claim data; 

FIG. 6 is a table containing examples of the question groups and particular 
question fields a user may be asked to complete in a process of capturing initial claim 
data; 

FIG. 7 A is a screenshot of a gateway question presented to a user in an initial 
claim capture system; 

FIG. 7B is a screenshot of questions presented subsequent and in response to an 
answer to a gateway question in an initial claim capture system; 

FIG. 8 is a screenshot of an interactive user interface, which allows a user to 
represent a damaged vehicle through varying the degree and location of damage to a 
representative vehicle graphic; 

FIG. 9 A is a business object model for a first notice of loss sub-system; 

FIG. 9B are the object attributes of the objects of the business object model of 
FIG. 9A; 
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FIG. 10 is a block diagram of the types of assignees the triage and assignment 
sub-systems can make assignments to; 

FIG. 1 1 is a flow diagram of a process of triage and assignment in accordance 
with the present invention; 

FIG. 12A is a screen shot of a list of claims; 

FIG. 12B is a screen shot of the details of a claim; 

FIG. 12C is a screen shot of a vendor search function that is driven by user 
selected criteria; 

FIG. 1 2D is a screen shot of a list of vendors; 
FIG. 12E is a screen shot of a vendor's details; 
FIG 12F is a screen shot of a record of assignment; 

FIG. 13 is a chart that represents data fields received or retrieved by the triage and 
assignment sub-systems; 

FIG. 14 is a list of data field and attributes that an assignment sub-system 
transmits an assignee as part of an assignment; 

FIG. 15 is a business object model for an assignment sub-system; 

FIG. 16 is a screen shot of a main screen of a vendor connection and assignment 
management system; 

FIG. 17 is a screen shot of a digital photo displayed through a Connection system; 

FIG. 18 is a flow diagram of an audit process; 

FIG. 19 is a block diagram of the systems and sub-systems that transmit, store, or 
retrieve claim data from an electron claim file repository; 

FIG. 20 is a business object model for an electronic claim file repository; 
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FIG. 21 is a business object model for an electronic claim file repository; 

FIG. 22 is a business object model for an electronic claim file repository; 

FIG. 23 is a block diagram of the systems, sub-systems and database that interface 
with a user interface and claim manager sub-system; 

FIG. 24A is a screenshot of a user interface and claim management system 
viewing and editing claim data feature; 

FIG. 24B is a screenshot of a user interface and claim management system 
viewing and editing digital images feature; 

FIG. 25 is a screenshot of a user interface and claim management system 
navigation feature; 

FIG. 26 is a block diagram of the participants in an automated payment process; 

FIG. 27 is a flow diagram of a process of automating claim payments; 

FIG. 28 is a screenshot of an example of canned or standard reports generated by 
a reporting sub-system; 

FIG. 29 is a screenshot of a report generated by a reporting sub-system that is 
indexed by region and by the states within each region; 

FIG. 30 is a screen shot of date elements generated by a report sub-system 
exported to a Microsoft Excel software program. 
V. Detailed Description of Preferred Embodiments 

1 . General Overview 

The present invention provides system and methods of administering, tracking 
and managing claims processing. More particularly, the system and method processes, 
tracks and releases funds for claims made upon insurance policies and similar risk 
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shifting mechanisms including but not limited to self insurance, indemnity provisions and 
surety and performance bonds. 

a. System Architecture 

A system architecture for practicing the methods of the invention is shown in 
FIG. 1 . The elements depicted on FIG. 1 include the computer systems, network 
connections and other communication devices that constitute the preferred physical 
embodiments to implement the described embodiment of the invention. It is understood, 
however, that the system is not limited to the mentioned devices and additional and 
alternative devices may be supported by the system. 

As shown in FIG. 1, a user (e.g., an insurance policy holder, a consumer claimant, 
an insurance carrier internal adjuster, an independent adjuster, a rental provider, or a 
repair facility) interacts with the system 30 through input/output devices 1 ("I/O 
devices")- These I/O devices include but are not limited to personal computer 2, wireless 
device 5, embedded device 10 and telephone 15. 

Personal computer 2 may be an IBM compatible computer, a Macintosh computer 
or any other system capable of running Client Software such as a Web Browser, although 
other client software may also be used as appropriate to the system. Personal computer 2 
preferably runs a Web Browser such as Netscape's Navigator or Microsoft's Internet 
Explorer to communicate information to and from system 30. Personal computer 2 is 
connected to a communication network 25, such as the Internet, using a fast connection, 
such as DSL, cable modem, wireless, modem, etc. Personal computer 2 preferably 
includes an output device, such as a monitor or other display and a speaker or printer 
(i.e., printer device 3). Personal computer 2 also includes an input such as a keyboard or 
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pointing device (e.g., mouse, track ball, pen device, microphone, joy stick, game pad, 
satellite dish, scanner or the like) or both to enable information to be input to the system. 

Wireless device 5 may include but is not limited to a communication device, 
including a telecommunication device or wireless Internet devices that a user carries and 
uses to enter and obtain information pertinent to the process. The wireless infrastructure 
that connects the device with the communication network 25 uses existing wireless signal 
receiving systems 20 such as, for example, the communication methods used by 3Com's 
Palm Pilot VIL 

Embedded device 10 may include but is not limited to a communication device 
embedded in the insured object, such as a vehicle or a home, that is capable of detecting, 
recording and transmitting to system 30 the information on the casualty that initiates a 
claim. Embedded device 10 preferably communicates the casualty information through 
wireless signal receiving systems 20 using a wireless device. Embedded device 10 may 
also transmit the casualty information through other communication lines such as 
telephone 15. 

Personal computer 2, wireless device 5 and embedded device 10 transmit requests 
and responses to system 30 through communication network 25 using standard protocols, 
such as XML, HTTP or the like. It is understood, however, that the system 30 is not 
limited to the mentioned standard protocols and alternative standard protocols may be 
supported by the system 30. 

When telephone 15 is used as an interface to system 30, telephone 15 transmits a 
number to telephony server 41 . Telephony server 41 includes the necessary software to 



12 



22606/05796/DOCS/l 159542.4 



recognize speech and convert it to a standard text format such as XML or the like that can 
be sent to Web server 45. Telephony server 41 can also be outside of system 30. 

The messages sent and received by the I/O devices 1 preferably use standard 
protocols when they are received by load balancers 40 and web servers 45. The preferred 
standard protocols include but are not limited to HTTP and XML protocols which are 
capable of being encrypted by Secure Socket Layer (SSL), Virtual Network Protocol 
(VPN) or similar encryption systems. 

Preferably, the computer systems in system 30 offer the highest performance, 
scalability and reliability. In one embodiment, the platform used is Sun Microsystems 
hardware running the Solaris operating system. 

Standard encryption mechanisms are used to ensure the confidentiality of data. 
When confidential data is transported between I/O devices 1 and system 30 or between 
external partner systems 62 and system 30, encryption systems (i.e., SSL or VPN or the 
like) may be used to protect the data. 

Firewalls 35, 60, 69, 79 and 93 ("firewalls") are specialized hardware and/or 
software components that filter requests traveling in and out of systems 30, 65, 75 and 90 
respectively. Certain input/output devices can also include firewalls (not shown). 

Firewall 35 is configured to accept only certain user request types, preventing 
undesired requests from being forwarded from communication network 25 to system 30. 

Web servers 45, 66 and 76 include, but are not limited, to servers running a Web 
server application. In one embodiment, such servers are provided by Netscape 
Enterprise, Apache software. 
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Firewall 35 sends requests to load balancer 40, which distributes such requests to 
one of the Web servers 45 in a Web Server farm. Web server 45 then forwards the 
request to application server 50 where a software application performs the appropriate 
business logic to satisfy the request. As part of the required business logic, the 
application accesses data stored in database server 55. 

Database server 55 runs a relational database management system (RDBMS). In 
one embodiment, the ROMS software Oracle 8i is used. The RDBMS software running 
in server 55 manipulates the data and sends the appropriate information to application 
server 50. 

Application server 50 may be, but is not limited to, a Java based server providing 
scalability and reliability to the application. The application runs on top of Application 
Server Software, in one embodiment, BEA's WebLogic software. 

The information required to complete the response to the request may not only 
require data from database server 55, but also data from one of the external partner 
systems 62. In one embodiment, the application server 50 sends a request to one of the 
external partner systems 62 via a secure communications medium 61, such as, privately 
leased lines or the like. These external partner systems 62 include insurance carrier 
system 65 or systems, vendor system 75 or systems, trustee bank system 90 or systems. 
A preferred format for the sent request is standard XML format, although other formats 
may be supported by system 30. A computer running the Adapter software running in 
Systems 67, 77, 86 or 91 translates the XML request to the format required by the 
insurer's system, such as Legacy systems 68, 78 or 92 Once legacy systems 68, 78 or 92, 
respectively retrieve or update the data inside their data stores, information is sent back to 
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adapter 67, 77, 86 or 9, which translates the message to XML and sends it back to 
application server 50. 

Legacy systems 68, 78, 87 or 92 include but are not limited to existing systems 
that the external partners use to store and process the data they use to perform their 
business. It is understood that insurer systems other than Legacy systems may be used. 

Application server 50 builds a response preferably in HTML or XML formats and 
sends it back to the I/O devices 1 that initiated the request. For example, in the case of a 
personal computer 2, the message transmitted to a Web Browser uses the HTML 
protocol. In the case of the embedded device 10 and wireless device 5, the message is in 
XML format. In the case of telephone 15, the message is an XML message ready to be 
converted into audible speech by telephony server 41. 
b. Logical Components 

FIG. 2 depicts the logical components that comprise the application software used 
to implement the present invention. In one embodiment, the application is designed 
using an Object Oriented and multi-tier approach to provide flexibility and ease of 
integration with external partner systems 62 and also to allow future modifications to the 
system 30. It should be understood, however, that the system 30 is not limited to the 
mentioned logical components and additional and alternative logical components may be 
supported by the system 30 

As shown in FIG. 2, the system 30 uses various user interfaces 204, including 
client software 205, voice based interface 207 and wireless interface 209. This layer 
corresponds to the I/O devices 1 in FIG. 1. 
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The client software 205 runs in a client machine such as personal computer 2 and 
has all the display and communication logic necessary to send and receive messages to 
and from the system 30 via a communications network 25. In a preferred embodiment, 
the client software 205 is a Web Browser. In a preferred embodiment, the client software 
205 is the user interface and claim management sub-system (Deskview) sub-system 200, 
described below. The voice based interface 207 enables a user using telephone 15 to 
communicate with system 30. 

The wireless interface 209 enables a user using a wireless deviceS to 
communicate with system 30. Wireless interface 209 is also used by a user using an 
embedded device 10. 

The application layer 213 may be hosted in Application Servers 50. All 
communications between the application layer 213 and the external partner systems 62 
are accomplished using enterprise application interface 217 software ("EAI" or "EAI 
Software"). The EAI software 217 manages message delivery and transaction integrity. 
Such EAI software may be purchased from Active Software or the like. The data to be 
communicated is converted into a standard format such as XML or the like by EAI 217. 
Adapter software 203 (residing in adapter machines 67, 77, 86 and 91 in FIG. 1) can 
convert the standard format to the format required by external partner system 62. 

The data layer 219 provides the ability to store, update and access data in an 
efficient and organized manner. In one embodiment, the functionality of data layer 219 is 
provided by a Relational Database such as Oracle 8L 

The electronic claim file repository (Eclaim database) 280 is a central repository 
for claim related and transactional data. In one embodiment, claim data including 
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administrative information related to insurance policies, policy holders (such as name, 
address, policy information, and transactions), consumers, and other users (e.g., insurance 
carriers, and vendors), as well as estimates, digital images, supplements, status of tasks 
related to the claim, and reports, is stored in the Eclaim database 280. The Eclaim 
database 280 is more fully described below. 

The directory 290 is a database storing industry data on businesses participating in 
a given industry. In one embodiment, data on service providers (e.g., independent 
appraisers, repair facilities, car rental facilities, towing providers, and glass repair 
providers) and supplier is stored in this database. In one embodiment, data on service 
providers includes name, service(s) provided, location, and hours of operation. In 
another embodiment, customer satisfaction index (CSI) data generated by consumers' 
questions and answers provided in response to a customer satisfaction survey, as well as 
other CSI information on the service provider, supplier and other business providing 
service for a given industry 

Application layer 213 comprises several sub-systems including application 
software programs for performing various functions within an application server 50. In 
one embodiment, the application layer 213 includes user authentication sub-system 215, 
EAI 217, Deskview sub-system 200, first notice of loss sub-system (FNOL) 210, triage 
sub-system 220, assignment sub-system 230, audit sub-system 240, automated payment 
sub-system 250, CSI collection sub-system 260 (CSI), reports sub-system 270. 

The user authentication sub-system 215 provides security control to the system 
30. The user authentication sub-system 215 requires a user to provide a valid user id and 
password combination. For new users, the user authentication sub- system 215 registers 
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the user, determines the user's level of access according to insurance carrier business 
rules (e.g., security tables), then stores the user authentication profile information (user 
id, password, level of access) on data layer 219. In another embodiment, user 
authentication information is stored on the external partner systems 62. Subsequently, 
each user who wishes to access the system must first be authenticated by the user 
authentication sub-system 215, which then determines what functional sub-systems of the 
system 30 the user is authorized to access and utilize, what data stored in the data layer 
219 the user is authorized to access and to what degree the user can edit or add to that 
data. 

The user interface and claim management sub-system (Deskview) 200 allows a 
user to access, view, add, and edit claim data. Deskview 200 also serves as a portal point 
to other sub-systems. 

The first notice of loss sub-system (FNOL) 210 captures initial claim data directly 
from a consumer using client software 205. In another embodiment, FNOL 210 captures 
initial claim data through a commercial participant. FNOL 210 presents the user, the 
consumer of the commercial participant, with tailored questions, where the presentation 
format varies depending on the type of user. Also questions subsequent to certain 
gateway questions presented to the user vary according to the user's answers to the 
gateway questions. The claim data captured can be transmitted to and stored in the 
eclaim database 280, or insurance carrier system 65. 

The triage sub-system 220 receives claim data and determines the severity and 
priority of the claim according to business rules established by an insurance carrier. 
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Next, the triage sub-system determines the type or type(s) of assignees to assign a claim 
to according to business rules established by an insurance carrier. 

The assignment sub-system 230 receives the claim from the triage sub-system 
220, identifies the assignee most qualified for the assignment according to insurance 
carrier business rules, makes the assignment, records that the assignment has been made, 
and notifies the assignee. 

The vendor connection and assignment management system (Connection) 300 
(Connection) does not reside on the application layer 213, but is stored and operates on 
the vendor's I/O device 1, and serves as a communication and management system for 
vendors, particularly service providers such as repair facilities and independent adjusters. 
In one embodiment, Connection 300 resides and operates on internal system 201. 

The audit sub-system 240 applies insurance carrier specific business rules, 
government regulations, and comprehensive trending analysis to detect and rectify any 
inconsistencies and irregular processing of claims, by auditing internal processes or user 
or service providers submitted data. 

The automated payment system (APS) 250 automates the process of fulfilling 
payments required to fulfill an asserted claim. 

CSI sub-system 260 automates the gathering of satisfaction data from a policy 
holder or consumer to generate a Customer Satisfaction Index (CSI) for the service 
providers. 

The reporting sub-system 270 summarizes and formats 459 data stored in the 
eclaim file 280 or the insurance carrier system 65 based on a number of criteria to 
generate various reports. Examples of reports generated by the reporting sub-system 270 
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are cycle times, conversion ratios, and current assignments outstanding. Reports can be 
generated upon each request or can be pre-generated and retrieved from storage in the 
eclaim database 280 or the directory database 290. 

In a preferred embodiment, system 30 is replicated in different locations and data 
is synchronized between the different locations to provide the highest level of reliability, 
c. Data Flow Relationship and Overall Process 

FIG. 3 is a block diagram of the data flow relationship between participants and 
sub-systems of a system of administering, tracking and managing insurance claim 
processing. FIG. 4 is a flow diagram of a process of administering, tracking and 
managing insurance claim processing. 

The first notice of loss (FNOL) 210 captures initial claim data directly from a 
consumer using client software 205 using, for example, the embedded device, wireless 
device, PC or telephone of FIG. 1. In another embodiment, FNOL captures initial claim 
data through a commercial participant, such as an insurance company call center. First, 
FNOL 210 receives 401 notice of loss from the user or other sources. Next, FNOL 210 
validates 403 the insurance policy under which the claim is being asserted. FNOL 2 1 0 
presents the user, the consumer of the commercial participant, with tailored questions, 
where the presentation format varies depending on the type of user. Also questions 
subsequent to certain gateway questions presented to the user vary according to the user's 
answers to the gateway questions. The user then fills out and submits 405 answers to the 
questions with which he is presented. FNOL 210 determines if the submitted 
questionnaire is complete and the answers submitted valid, and creates 407 a new claim 
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record for that claim. The claim data captured can be transmitted to and stored in the 
eclaim database 280, or insurance carrier system 65, 

The triage sub-system 220 receives claim data and determines scores 409 the 
claim according to insurance carrier business rules. The score is then used to determine 
the severity and priority of the claim according to business rules. Next, the triage sub- 
system classes 41 1 the claim according to business rules. The score and/or class of the 
claim are then used to determine 413 the type or type(s) of assignees to assign a claim to 
according to business rules. 

The assignment sub-system 230 receives the claim from the triage sub-system 
220, checks the profiles 415, which are stored in the directory database 290, of assignees 
of the determined type against profile preferences established in business rules. Next, the 
status of the assignees that meet the profile requirement is checked 417. The assignee 
that is of the determined type, meets the profile requirements, and has capacity to 
complete the assignment is identified and the assignment is made to that assignee. The 
assignee is then notified and the assignment is recorded. 

Connection 300 retrieves 421 claim data associated with an assignment. Next, 
Connection 300 requests an estimate from an estimate system and receives 423 an 
estimate with estimate details from the estimating system. Alternatively, a human may 
provide an estimate to connection 300. Subsequently, Connection 300 submits the 
estimate to the system 30, which stores the estimate in the eclaim database 280. 

The audit sub-system 240 applies insurance carrier specific business rules, 
government regulations, and comprehensive trending analysis to detect and rectify any 
inconsistencies and irregular processing of claims, by auditing internal processes or user 
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or service providers submitted data. The audit sub-system 240 can review 427 an 
estimate made and determine if it is unreasonable or if there is a potential for fraud. If 
the estimate is approved 433, the assignee is notified and service 435 of the assignment 
begins. If the audit sub-system 240 determines that the estimate is unreasonable, the audit 
sub-system 240 notifies an insurance carrier adjuster to review to the estimate. 

The adjuster determines whether to approve 431 the estimate. If the estimate is 
not approved, the adjuster contacts the service provider to determine a reasonable 
estimate and a new estimate is submitted 425. 

Once the estimate has been approved 433, and after the service starts 435, the 
automated payment system 250 is employed. 

The automated payment system (APS) automates the process of fulfilling 
payments required to fulfill an asserted claim by an insurance company. APS receives 
payment requests made, validates the claim under which the request is made, validates 
the request and automates payment. In the case of reception of an estimate, APS may 
make progress payments according to insurance carrier business rules. At step 437, APS 
determines if the service provider is a trusted trading partner. In one embodiment, this is 
done by using the service provider specific data from the system 30's service provider 
directory database 290 or on the eclaim database 280. If the service provider is trusted, 
and the business rules authorize progress payments, the APS directs that Trust/Bank 
system 90 to release portions of payment outstanding of the total claim on a continuum 
that is stipulated by the business rules to match the progress of the service. When the 
service provider is not trusted, payment is reserved until services are completed. 
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Once services are completed 451, APS requests the consumer complete a 
certificate of satisfaction through use of and I/O device 1 . Once the certificate of 
satisfaction is received, APS notifies the Trustee Bank system 90 to release the remaining 
balance of the payment amount to the vendor. If the vendor is trusted, any remaining 
amount is paid. If the vendor is not trusted, the full amount is paid. The financial record 
stored on the eclaim database 280 or the insurance carrier system 65, and the account on 
the Trust/Bank system 90 are updated to reflect this payment. 

CSI sub-system 260 uses both structured questions with predefined possible 
answers including multiple choice answers and unstructured questions to be answered 
using free text gathered from a policy holder or consumer to generate a Customer 
Satisfaction Index (CSI) for the service providers. The CSI is stored into the directory 
database 290. When the claim services are completed, the consumer completes the 
consumer satisfaction survey via a client software 205 interface or a voice based interface 
207. Preferably, the consumer uses his or her I/O Device 1 to review the customer 
satisfaction survey questions stored in the eclaim database 280 and are retrieved by the 
CSI sub-system 260. Alternatively, the consumer completes a paper version of the 
survey and sends that to a data entry group that uses I/O devices 1 to forward the 
responses to the CSI sub-system for storage in the eclaim database 280. 

The results of the consumer satisfaction survey are retrieved from the eclaim 
database 280 compiled by the CSI sub-system 260. The CSI sub-system uses an 
algorithm to generate a composite index for the survey and updates the overall index for 
that service provider in an entry to industry directory database 290 incorporating the new 
result. The resulting overall CSI index for a given vendor can be displayed with the 
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profile of the assignee the next time the service provider's data in industry directory 
database 290 is accessed from the system 30, particularly the assignment sub-system 230. 

Finally, the reporting sub-system 270 summarizes and formats 459 data stored in 
the eclaim database 280 or the insurance carrier system 65 based on a number of criteria 
to generate various reports. Various users are able to view these reports through a client 
software 205 interface. In one embodiment, the reporting sub-system 270 utilizes 
software provided by Crystal reports and the like to facilitate the creation of the reports. 
In a preferred embodiment, the originating database (eclaim database 270, the directory 
database, or the insurance carrier system 65 database) that the reports are generated from 
is replicated and the reports are generated from that replicated mirror database so as not 
to burden the originating databases. 

d. General Principles: Variable Automation, Standalone or in 

Conjunction with Other Sub-systems, and Business Rules and 
Rules Based Systems, and communication with other parties. 
(1 ) Variable Automation 
In one embodiment, each of the sub-systems automates claims processing tasks to 
a variable degree depending on business rules. Business rules can require that, in 
response to certain data conditions, a claims processing task be turned over to a human 
participant such as an insurance adjuster. For example, if the audit sub-system 240 
determines through comparison with actuarial analysis of stored claim data on past claims 
that a claim submitted or an estimate submitted is likely fraudulent, the audit sub-system 
240 would notify a Special Investigating Unit (SIU) of the potential fraud and assign the 
task of estimate review to the SIU. Even in a fully automated mode of operation, 
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according to insurance carrier business rules, the sub-systems enable human intervention 
and exception handling for certain circumstances. 

(2) Operation as standalone systems or in conjunction 
with other sub-systems 

In one embodiment, the sub-systems of the system 30 operate in conjunction with 
one or more sub-systems and one or more of the databases of the system. In an alternate 
embodiment, each sub-system can operate on a standalone basis in conjunction with one 
or more insurance carrier systems 65. 

(3) Business Rules and Rules Engines 
Business rules utilized by sub-systems of the system 30 are designated and/or 

approved by the insurance carrier and can be updated and modified. In one embodiment, 
the business rules applied by sub-systems described above are stored in the data layer 
219. In another embodiment, each set of business rules utilized by each sub-system of 
the system 30 are incorporated into the sub-systems at the application layer 213 and 
comprise a business rules engine component of each sub-system. The general concept of 
business rules will be known to persons of ordinary skill in the art. The specific rules 
used to accomplish the functionality described herein, contain content specific to 
implementation of this invention. In one embodiment, business rules incorporated in 
business rules engines are also designated or approved by the insurance carrier and can be 
updated and modified. 

(4) Transmission of Data to Other Parties 
Sub-systems communicate with other parties (e.g., insurance carriers, vendors, 

policy holders, consumers) providing a variable degree of information (e.g., 
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administrative information, if and who the claim has been assigned to, status of each step 
in the process). Information transmitted can be sent directly via mail, fax, phone, email, 
or page or in other means that can be accessed through I/O devices. In one embodiment, 
sub-systems or systems of the invention can communicate to parties indirectly, through 
posting data to a website or transmission of the data to the eclaim database 280 coupled 
with notification to the intended receiving party that the data is stored on a website or the 
eclaim database 280 along with sufficient access and reference to enable that party to 
locate and retrieve the data. For example, assignment can post data on who a claim has 
been assigned to a website or the eclaim database 280, and then provide notification and 
access and retrieval information to a policy holder, for instance, such that the policy 
holder can retrieve that information and related information without the need to contact 
the insurance carrier or the system 30 directly through phone calls or other means. In 
another example, APS can periodically post the status of payments to a website and 
eclaim database 280, and notify a payee that the status of their payment request is posted 
on a website or the eclaim database 280 with access and retrieval information. 
Subsequently, payees can have direct access to the updated status information at their 
convenience. 

2. The First Notice of Loss Sub-System (FNOL) 
a. General 

The first notice of loss sub-system (FNOL) 210 captures initial claims data. As 
shown in FIG. 3, FNOL 210 may be implemented in conjunction with other sub-systems 
and databases of the system 30. However, in an alternate embodiment, FNOL 210 can 
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operate on a standalone basis in conjunction with a single or multiple insurance carrier 
systems 65. 

FNOL 210 can be implemented to allow an user, for example, a consumer, i.e., 
any individual who is not a policyholder and is not acting on behalf of a commercial 
participant (e.g., a claimant claiming damages under an insurance policy caused by a 
policy holder), a policy holder, i.e., any individual who has a policy with the insurance 
carrier involved, and a commercial participant, i.e., a party acting on behalf of the 
insurance carrier involved (e.g., a call center representative, an insurance agent, or an 
insurance adjuster) to input initial loss information over a web based channel. In one 
embodiment, the web-based channel is available 24 hours a day. 
b. Process 

Referring to FIG. 5 A, a flow diagram of the process of capturing initial claim 
data, in step 502, the user initiates the claims process using an I/O device 1. In one 
embodiment, the process is initiated via an insurance carrier's system 65. In another, the 
user connects to the insurance carrier's website and begins to file a claim of loss based on 
insurance carrier rules. Next, the consumer selects 504 to submit a new claim loss, which 
interfaces the user to FNOL. FNOL 210 can be branded for that insurance carrier. In 
another embodiment, a user can directly connect to FNOL 210 in the application layer 
213 and initiate the process of capturing initial claim data. 

In step 506, the user completes an initial set of questions geared to determining 
whether the user's claim is being made under a valid insurance policy. The user is asked 
to supply required data elements such as name of the user, relationship to claim, policy 
number, and date of loss. 
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In step 508, FNOL 210 will verify if the policy is valid. In one embodiment, this 
is done by accessing the insurance carrier's system 65 to retrieve the policy profile 
information including policy and coverage data and then comparing it with the data 
entered. In another embodiment, the policy profile information necessary to validate the 
user's claim is stored on the eclaim database 280. If the policy information necessary to 
validate the user's claim is stored on the insurance carrier system 65 and FNOL 210 is 
unable to connect with the insurance carrier system 65 to confirm and potentially retrieve 
the necessary insurance policy information, FNOL 210 can continue to capture claim 
information, store the claim information received, but will not be able to complete the 
transaction nor assign a claim number until FNOL 210 is able to connect to the insurance 
carrier system 65 to confirm that the policy information matches a valid insurance policy. 

If the policy is not valid (e.g., there is no record of the insurance policy being 
asserted or the date of the loss is outside of the policy coverage period), an error message 
will be returned to the user and the user will be given additional opportunities to enter 
valid policy information. For example, the policy information may have been entered 
incorrectly and no matching policy exists. If valid policy information is still not entered 
after a set number of attempts, e.g., 5, the user will be informed that an error has 
occurred, that the user should contact the insurance carrier, and will be given 510 the 
insurance carrier's contact information. FNOL 210 also determines if the policy 
information entered violates insurance carrier business rules and automatically 
implements actions stored to handle such violation (e.g., if the date of loss is outside of 
the policy period, then FNOL 210 communicates to the user that the user should contact 
the insurance carrier and provides the insurance carrier's contact information). In one 
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embodiment, after the claim is initiated the consumer is asked to identify what type of 
loss they wish to report (e.g., automobile, life, renters, health, and homeowners). This 
information will help to funnel off claims that are not be appropriate to report through 
FNOL 210 and may help with the triage sub-system 220 and assignment sub-system 230 
described more fully below. 

If the policy information entered in step 508 is valid, the user is presented with a 
second set of questions to fill out and submit. In one embodiment, certain policy data 
that relate to insured vehicles, drivers, and coverage, which are stored on the insurance 
carrier's system is retrieved and used to pre-populate corresponding data fields within the 
second set of questions the user is presented with. 

FIG. 6 is a table containing examples of question group fields (questions sets) and 
particular question fields a user may be asked to complete. Certain questions can be 
designated as mandatory fields according to insurance carrier business rules. 

At any time after an authenticated user has accessed FNOL 210, the authenticated 
user may save the information added for the loss to that point as unfinished. This saves 
the information entered so that the user can come back to it at a later point and finish. 
Once the user chooses to save an incomplete set of initial claim data, notification is sent 
back to them that the save was successful, and information necessary to retrieve their 
saved claim at a later time is provided. Additionally, a warning should be displayed that 
any information saved as unfinished will be purged from the system in 7 days and that no 
notices have been or will be sent to the carrier about this loss unless it is completed. 

Next, after all question sets have been completed and a user believes that all the 
information about the loss has been entered, the user submits 512 the entire set of 
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answers to FNOL 210. FNOL 210 then determines 514 if at the very least, the mandatory 
fields are answered and filled with valid information. In the case of missing or invalid 
information, the insurance carrier system 65 is able to designate how FNOL 210 will 
respond. Examples of potential responses: if the user leaves one or more required fields 
blank - the user will be reminded to complete the fields marked as required before 
proceeding, if the user inputs invalid information into a required field - message will 
display listing the fields that are in error along with valid formatting for each field, and if 
the user experiences either of the above errors and is unable to correct them. After the 
third attempt, an additional message will be displayed 510 directing the user to contact 
the insurance carrier and offering the insurance carrier's contact information. If all 
mandatory fields are completed with valid information, FNOL 210 stores 516 the 
complete set of initial claim data on the eclaim database 280 and may assign it a claim 
number. In one embodiment, after a user completes, and submits each set of questions, 
FNOL 210 determines if at the very least, the mandatory fields have been answered and 
are filled with valid information. If mandatory fields have not been satisfactorily 
completed FNOL 210 responds according the business rules. 

Next, the complete set of initial claim data and the claim number, if assigned, is 
transmitted 520 to the insurance carrier system 65. Also, if FNOL 210 assigned a claim 
number, it is transmitted 518 to the consumer or policy holder. The insurance carrier 
system 65 then stores the set of initial claim data, and may assign it a claim number, if 
FNOL 2 1 0 had not previously. If a claim number has not been assigned previously by 
FNOL 210, the insurance carrier system 65 assigns 522 the claim a claim number, 
attaches the claim number to the claim data, and transmits the claim number to the 
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consumer or policy holder and to the eclaim database 280. The eclaim database 280 then 
attaches the claim number to the set of initial claim data. 

In another embodiment the set of initial claim data is stored solely on the eclaim 
database 280. The insurance carrier is transmitted notice that a new claim has been filed 
and captured, and sufficient claim identification information such that the insurance 
carrier system 65 or insurance carrier representatives can access the claim data stored in 
the eclaim database. In one embodiment, notice and the claim identification information 
are transmitted via email or fax. 

In another embodiment, FNOL 210 transmits the complete set of initial claim data 
and the claim number, if assigned, to the insurance carrier system 65. 

c. Varying Presentation Layers and Questions Presented by User 
Type 

In one embodiment, FNOL 210 presents distinct user interfaces to user according 
to type of user. A different user interface is presented to and utilized by commercial 
participants, e.g., agencies or call centers (carrier operated or outsourced) as compared 
with policy holders and consumers. The user interface is tailored to the user type, with 
the interface for commercial application provides increased functionality over the one for 
consumers. 

For example, whereas a user who is a consumer or policy holder may be 
presented a series of questions and answers over a larger number of spaces with a greater 
deal of explanation into how to answer each question, the commercial user is presented 
with fewer question and answer sets and may instead be presented a greater amount of 
designated fields and a greater density of questions or fields. 
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FIG. 5B a flow diagram of a commercial participant's process of capturing initial 
claim data. A commercial participant logs 524 into a website using an I/O device 1. The 
commercial participant selects 526 FNOL 210 option to capture or report initial claim 
data. The commercial participant than selects 530 an insurance carrier the claim is being 
filed under and enters policy information. If policy information is invalid a warning is 
displayed 536 to the user. If the policy information is valid FNOL 210 determines 538 if 
there are any duplicate claims filed. If there are potential duplicate claims filed, FNOL 
210 displays 540 summary details of the potential duplicates. For either case of a claim 
being filed under an invalid policy or if duplicate claims have been potentially filed, 
FNOL 210 provides suggestions to the user as to how to proceed based on insurance 
carrier rules, which could include proceeding to collect the initial claim data, or to 
terminate the claim data capture process and refer the situation to an insurance carrier 
adjuster or customer service center. The subsequent steps are similar to the process of 
capturing initial claim data implemented for a non-commercial participant, 
d. Gateway questions 

FIG. 7 A is a screenshot of a gateway question presented to a user via his browser 
in an initial claim capture system. 

FIG. 7B is a screenshot of questions presented subsequent and in response to an 
answer to a gateway question in an initial claim capture system. 

In one embodiment, FNOL 210 presents the user with gateway questions, the 
answers to these gateway questions determine whether and what subsequent questions 
will be presented to the user. For example, has anyone been injured in the accident? 
Were any other persons involved (e.g., witnesses, pedestrians, bicycle riders)? If the 
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answer is no, another gateway question may be presented. If the answer is yes, the user is 
presented with additional questions related to that gateway subject. Another example, an 
automobile claim will have questions relating to bodily injury. If the consumer answers 
in the affirmative, there will be additional questions to provide detail about the injured 
parties and the sustained injuries. 

e. Attachment of Digital Photographs and Images 

In one embodiment, a user attaches digital photographs, scanned images, or 
documents to the claim questionnaire submitted. Digital images stored in standard digital 
formats and scanned images scanned by a TWAIN-compliant scanner can be attached to 
a questionnaire submitted through FNOL 210. For example, a photo of a damages car 
can be attached. 

f. Interactive Graphical depiction of damage 

FIG. 8 is a screenshot of an interactive user interface, which allows a user to 
represent a damaged vehicle through varying the degree and location of damage to a 
representative vehicle graphic. 

In one embodiment, FNOL 210 interactively questions user to graphically 
represent the degree of damage a vehicle has sustained. Through a series of questions 
separated by feedback graphical representations of the user's answers, FNOL 210 assists 
the user in creating an accurate graphical depiction of a damaged vehicle. FNOL 210 
presents a user with a question as to what damage, the location of damage, and the degree 
of damage a vehicle has sustained. In addition, FNOL 210 provides guidelines, in the 
form of text or in the form of representative graphics or digital photographs or images as 
examples of types and degree of damage according to location and severity. In a further 
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embodiment, graphics or digital images can be produced which match or are similar to 
the make and model of the vehicle whose damage is being graphically represented. 
Graphics can be two-dimensional or three-dimensional. 

For example, if the user selects moderate front end damage to a vehicle, FNOL 
210 would alter a graphic of a vehicle to represent moderate front end damage. 
Subsequently, if the user did not find the graphical representation to be accurate, he could 
change alter his selection of damage location and degree and would be presented with a 
new depiction of his selection. When the user finds the depiction to be accurate, the 
graphical depiction is stored along with other claim data. For example, FIG. 8 is an 
interactive user interface to varying the degree of damage to a representative vehicle 
graphic. The vehicle graphic starts in an undamaged state, but changes as and according 
to the user's input as to the location and degree of damage. Each user submission of 
location and degree of damage changes the graphic, until the user is satisfied with the 
depiction and submits the depiction. 

In another embodiment, user described damage is matched with a digital library 
with images of damaged vehicles. Images that are determined to resemble the damage 
reported by the user are retrieved and presented to the user for comparison. If available, 
vehicle make and model criteria can be searched and matched to return digital images of 
damage vehicles of the same make, model and potentially year as the vehicle the user is 
attempting to describe. In another embodiment, the user is presented with slide bars to 
represent the degree of damage and can control the location of the damage by the 
reporting the angle from which the vehicle was damaged (e.g., one o'clock, 12 o'clock). 
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FIG. 9A is a business object model (BOM) for an implementation of a FNOL 210, 
which with FIG. 9B, which is a list of object attributes for a the business object model of 
FIG. 9A, provides an explanation of and relationship between the objects used in a 
preferred implementation of the invention. 

3. Triage sub-system and Assignment sub-system 
a. General 

The triage sub-system 220 and assignment sub-systems 230 automate, to a 
variable degree (e.g., full automation vs. limited automation that requires user interaction 
to complete the process), the process of identifying tasks that need to be completed to 
fulfill an insurance claim, determining which type of assignees, e.g., a service provider, 
vendor, internal work group or individual assignee are necessary to fulfill the claim, 
determining which individual assignee is most well suited to fulfilling each specific task 
and assigning each assignee a task, for processing and/or review. The types of 
assignments available include: appraisal, estimate, estimate review, repair, rental, or 
towing assignments. The triage sub-system 220 and the assignment sub-system 230 
provide a variety of users within carrier claim staff (i.e., adjuster, Claims Clerk, estimate 
reviewer) or consolidators with an efficient method of delegating work assignments 
electronically. In another embodiment (described below), the triage and assignment 
process is fully automated. 

In one embodiment, as shown in FIG. 3, the triage and assignment sub-systems 
are implemented in conjunction with other sub-systems of the system 30, for example, 
the eclaim database 280, FNOL 210, and Deskview 100. However, in another 
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embodiment, the triage and assignment sub-system 230s operate in combination or on a 
standalone basis in conjunction with a single or multiple insurance carrier systems 65. 

FIG. 10 is a block diagram of the types of assignees the triage sub-system 220 and 
assignment sub-system 230 can make assignments to. 

The triage sub-system 220 assigns a priority order to claims on the basis of where 
funds and resources can be best used or are most needed, as well as a class of the claim, 
so that the claim can be accurately assigned. The assignment sub-system 230 appoints 
responsibility for a claim or a portion of a claim to an assignee (e.g., a Repair Facility, an 
Independent Adjusting Firm, a work group within an Insurance Carrier, a specific 
adjuster or a combination of assignees), 
b. Process 

FIG. 1 1 is a flow diagram of a process of triage and assignment in accordance 
with the present invention. FIG. 13 is a chart that represents data fields received or 
retrieved by the triage and assignment sub-systems. First, the triage sub-system 220 
receives 1101 or retrieves an insurance claim record, similar to the example in FIG. 13, 
that contains data elements from either the eclaim database 280 or from the insurance 
carrier system 65. 

i. Scoring Claim Data 
Next, the triage sub-system 220 scores 1 103 the insurance claim by retrieving and 
applying a set of the insurance carrier's business rules, which can be seen as an insurance 
carrier scoring table, stored on the insurance carrier system, to the claim data. Scoring 
simply assigns different aspects or elements of the claim according to the insurance 
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carrier's business rules, and then sums the numeric values associated with different 
aspects of a claim. Scoring sets the priority of the claim and may weigh such factors as: 

• Reported by person/relation 

• Reported on date 

• Loss type 

• Date of loss 

• Time of loss 

• Loss location (state, city, zip & 
county) 

• Number of vehicles involved 

• Number of parties involved 

• Types of parties involved 

• Location of parties 

• Loss description 

• Damage to vehicle 

• Location of vehicle 

• Vehicle drivability 

• Damage to other property 

• Location of property 

• Property livability 

• Injuries involved 

• Types of medical treatment 

• Type of policy 

• Type of coverage 

• Repair partners chosen 

• Amount of damages 

• Policy information 

• Agency information 

• Regulatory conditions 

These factors are scored according to an insurance carrier's business rules via a 
rules based system. Examples of the application of the business rules to the claim 
elements are: 

• A point could be added for each vehicle involved in a claim. 

• A point could be added if there is damage to something other than a vehicle. 

• A point could be added for each non-injured person involved. 

• Several points could be added for each person involved. 
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• Points could be added for different types of claims - Collision with a fixed object 
might get one point where Collision with another vehicle by rear ending it might 
get two and Collision with another vehicle in an intersection might get five. 

• Multiple points could be added if a bicyclist or pedestrian was involved. 

• Multiple points could be added if the claim is from a more complex policy type 
that requires more coverage investigation. 

• Points could be added if the car was a theft. 

In addition, factors such as damage to vehicles, damage to property, or physical 
injuries may have an associated severity weighting that will contribute to the score that 
element receives. Next, the score assigned for each element of the claim are summed. 

The summed score is used to determine 1 105 the severity and priority of the claim 
according to the insurance carrier business rules. For example, a claim that receives a 
high summed score likely represents a complex, high damage and high cost claim. 
Determining the severity also will apply to determining the type of assignee the claim 
will be assigned to. For example, a claim with an extremely low score (under 5) might 
qualify to be handled completely by a repair facility without an adjuster needing to be 
assigned. One that scores under 20 might go to a fairly new adjuster. A claim that scored 
over 50 might only go to a seasoned specialists. In addition to scores, there could be 
additional rales that even if the score only amounts to 3 but there was an injury, the 
system would have to assign an adjuster in addition to the repair facility, since the 
repairer cannot handle the injury. 

The summed score and the severity can be used to determine the priority of a 
claim, i.e., the order in which it is processed relative to other claims. The priority and 
order of processing of a claim can differ according to insurance carrier business rules. 
For example, some insurance carriers may prioritize the processing of low scored claims 
that have low severity because low scored claims are usually less complex and are able to 
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be turned over quickly. In contrast, some carriers may do the opposite and prioritize the 
processing of high scored claims that have high severity because they high severity 
claims may require more attention. 

ii. Classing a Claim 

Next, the claim is classed 1107. Classing puts a claim, based on alphanumeric 
strings of values for specific fields in the claim (e.g., the fields that hold the year, make, 
model data for a vehicle), through a series of tests that are set by the business rules to 
determine a "class" of claim. Once the class of the claim is determined, the designated 
class is then used to determine, through application of insurance carrier's business rules, 
which type or types of assignees to assignee the claim. For example, the triage sub- 
system 220 220 might receive claim data for a claim on a 1999 BMW 750. An insurance 
carrier rule may be to class all claims filed on BMW 750's that are a model year of 
greater than or equal to 1997 as a "new luxury car" class. This class, the "new luxury car 
class" may then have a business rule that requires all "new luxury car" class claims to 
have an independent or internal adjuster assigned to the claim. 

Once the score and the class of a particular set of claim data are determined the 
score and the class, in conjunction, through the application of the insurance carrier 
business rules, are used to determine 1109 the type or types of assignees that are 
necessary to fulfill the claim. The types of assignees can be determined by tests as 
simple as any individual data value that returns a class or score above a certain limit set 
by a carrier, a combination of class and score that is beyond a certain threshold, up to 
combinations of multiple value scores and classes that fall inside or outside of 
parameters. Some insurance company business rules are very simple tests and have a 
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limited number of corresponding types of assignees to assign the claim to. Other 
business rules will designate elaborate tests in order to classify new claims and many 
potential assignees. 

Also, where the score and class can be used in conjunction to determine the type 
of assignee to assign a claim to, certain "class" designations may be weighted higher and 
overrule a score designation that would normally result in a certain type of assignee being 
flagged. For example, an insurance carrier business rule may be that an internal adjuster 
will always handle a particular class of claims (for example, all claims involving a 1999 
Ford Explorer). So, if this "class" of claims is detected by the triage sub-system 220 220, 
the claim could be directed to the internal adjusting staff as opposed to the repair provider 
regardless of the total score of the claim. 

As another example, the class of "Non listed driver" is applied any time a driver 
for the insured vehicle is indicated that is not listed on the policy, and the class of "Single 
Car accident/Late night accident" is applied anytime two circumstances occur on the 
same claim: the loss involved only the insured vehicle and the time of loss was between 
midnight and 6:00 am. 

Using these examples, the separate score of either of the two examples listed 
above could easily be low, indicating that these claims might qualify for automated 
adjusting by directing the claim to a repair facility and then automatically paying the 
estimate. However, each of these classes of claims represents a significant exposure to 
the insurance carrier in terms of the claimant not having coverage for the loss or from an 
underwriting aspect. Therefore, a claim been designated as either class might be directed 
internally to a non-automated process no matter how low the claims score. 
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In another embodiment, what type or types of assignees that a claim will be 
assigned to can be determined by the triage sub-system 220 through the application of 
business rules to the claim data without the process of scoring and classing. For example, 
the triage sub-system 220 can identify what basic type of assignee to assign the claim to 
through the application of the insurance carrier's business rules and policy information 
stored on the insurance carrier's policy database as applied to the insurance data. For 
example, claim data received by the triage sub-system 220 may reveal a claim involving 
damage to the insured vehicle that is drivable, while insurance claim policy information 
retrieved from the insurance carrier's policy database reveals the claimant has collision 
coverage and rental reimbursement coverage. The triage sub-system 220 can then 
identify that there is a need for a Repair Facility and Rental Company. If, for example, 
the car also is not drivable, the triage sub-system 220 also identifies that a towing 
company may be needed. Determining which types of assignees to assign a claim to and 
the class of a claim are parallel to determining the types of tasks need to fulfilled to 
satisfy a claim. In one embodiment, the triage sub-system 220 determines specific tasks 
that are required to satisfy the claim and determines a type or types of assignees to assign 
each of those tasks to. 

c. Assignment 

The assignment sub-system 230 is utilized after the triage process identifies the 
type or types of assignee(s) that is need to fulfill the claim. 

i. Profile matching 

First, the assignment sub-system 230 checks 1111 the profile of assignees of the 
type designated by the triage sub-system 220. The assignment sub-system 230 checks the 
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profiles of assignees to match insurance claim data (e.g., owner address or vehicle 
location) to a group of specific potential assignees of the determined type according to 
insurance carrier business. Assignee profile information (e.g., name, function, address, 
customer satisfaction index (CSI) score, and rates charged) is stored in the directory 
database 290, which contains profile information on potential assignees. In an alternate 
embodiment, assignee profile information is stored on an external database, such as an 
insurance carrier system 65 database, accessible to the assignment sub-system 230. In 
one embodiment, the CSI score is one component in an assignee's profile is generated by 
and provided by the CSI sub-system 260. 

The assignment sub-system receives the profiles for each type of assignee 
designated by the triage sub-system 220 to which to assign the claim. Specific claim data 
elements from the claim record will be checked with profile data for each assignee that 
the insurance carrier has selected as assignment criteria in accordance with insurance 
carrier business rules. Those assignees of the specific type that match the profile will be 
selected. 

As a specific example, a business rule may be that only assignees of a given type 
who are within 50 miles of the vehicle location may be assigned a repair assignment. 
The assignment sub-system 230 then retrieves the vehicle location, which is piece of 
claim data and matches that with the store location for assignees of the given type 
according to the business rule of being within 50 miles of the vehicle. All assignees that 
match those criteria are retrieved. As a further example, to differentiate between 
assignees of the given type who meet the first business rule, the potential assignees that 
are retrieved can be ranked or can be further narrowed down based on CSI score, average 
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rates, and average cycle times, which are generated by the reports sub-system 270 and 
added to the assignee profile in the directory database 290. 

( 1 ) The Directory Database 
The directory database 290 can be grouped by type of assignees (e.g., repair 
facilities, independent appraisers, rental providers) and contain standard administrative 
information such as assignee names, addresses, and phone numbers. In one embodiment, 
the directory data is retrieved from electronic yellow pages. In one embodiment, in 
addition to administrative information, the directory database 290 stores information such 
as maps to the assignee location, work rates, as well as such information as CSI index 
scores, status/capacity to work, which can be updated by the assignee or estimated using 
reports such as cycle time and the number of assignments currently made to the assignee 
as are generated by the reports sub-system 270 and also stored to the assignee profile. 
Reports generated by the reports sub-system that are vendor specific (e.g., a particular 
vendor's cycle time (average time to complete an assignment) or an the aggregate 
number of assignments a particular vendor has be assigned over a particular period of 
time) are stored in the directory database 290. In one embodiment, vendor specific data 
such as vendor specific reports are linked to the eclaim database 280. In one 
embodiment, the directory database 280 interfaces with insurance carrier systems 65. 
ii. Check Status 

Next, taking the assignees whose profiles meet the assignment criteria set by the 
insurance carrier business rules, the assignment sub-system 230 accesses the status or 
schedule/workload of each potential assignee stored in the directory database 290 to 
determine 1 1 1 3 the current status or capacity of a given assignee. 
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In one embodiment, capacity can be determined by the assignment system by 
reviewing data such as history, cycle time, and the amount of assignments assigned to a 
given assignee generated by the reports sub-system 270 and stored in association with 
each assignee profile in the directory database 290. In another embodiment, the 
assignment sub-system 230 can retrieve currently updated copies of a potential assignee's 
schedule. In one embodiment, status data from assignees' calendar systems such as 
Outlook are imported into the assignee profile. In one embodiment, for internal 
insurance carrier and field staff, the assignment sub-system 230 receives data directly 
from the insurance carrier system 65 regarding each staff adjuster's status, 
iii. Identify Specific Assignee(s) 
The assignment sub-system 230 then determines 1115 algorithmically, according 
to insurance carrier business rules which assignee has the greatest capacity to accept the 
assignment, and assignees the particular task to that assignee. 

Assignment can be made to a carrier, any internal entity within a carrier 
(department, unit, manager, adjuster), an external adjusting source (Independent 
adjuster), or a vendor or to more than one of these. There could be multiple assignments 
on a single claim depending upon carrier specifications. One assignment could be to a 
vendor (such as a repair facility) for a damage estimate, while another could be to an 
Special Investigation Unit investigator to investigate a potential case of fraud in the initial 
claim, while yet another could be made to an internal bodily injury adjuster. 

In certain circumstances (e.g., selection of repair facility or rental provider) 
whether for legal reasons (e.g., anti-steering regulations) or efficiency concerns, before 
an assignment can be made, the assignment sub-system must obtain authorization of the 
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selection of assignee from the policy holder or consumer who filed the claim. 
Authorization can be obtained through notifying the policy holder or consumer of a 
recommended assignee or a list of recommended assignees, and receipt of selection of 
assignee or authorization to choose the assignee determined by the assignment sub- 
system 230. Notification and authorization capture could be implemented electronically 
(e.g., through email), through verbal communication confirmation received by an 
insurance carrier representative (e.g., a call center representative or insurance carrier 
adjuster operating a semi-automated assignment sub-system 230), or through any I/O 
device 1. 

iv. Notification, updating the databases, and logging the 

transaction record. 

Next, the assignment sub-system 230 notifies 1117 the assignee that the 
assignment has been made. In one embodiment, all transmissions to an assignee are via 
the notification method (e.g., an Connection 300, email, fax, mail, phone) established in 
the profile for that assignee. 

In one embodiment, the assignment sub-system a claim file, similar to the 
example in FIG. 14, containing insurance claim information and details of the assignment 
are transmitted to the assignee. In another embodiment, with notification of assignment 
the selected assignee is transmitted sufficient data, such as a user id and password to 
access claim data related to the assignment stored in the eclaim database 280. 

Once the assignments have been identified and the assignees have been notified, 
if the assignment sub-system 230 the eclaim database 280 is updated 1119 with details of 
the assignment (e.g., the claim data, which assignee(s) the claim was assigned to). In one 
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embodiment, a link is provided to the assignee profile stored in the directory database 
290 from the assignment details updated to the eclaim database 280. In another 
embodiment, once the assignments have been identified and the assignees have been 
notified, the insurance carrier system 65 is updated with claim information and details of 
the assignment to reflect the assignment. In another embodiment, once the assignment 
has been made the insurance carrier system 65 is notified of the assignment and provided 
with sufficient information to access claim data that relate to the claim and reflect the 
assignment. 

In one embodiment, an entry of the assignment is logged in the transaction record 
stored of the eclaim database 280 in association with the insurance claim. 

v. Updating the business rules, profiles, and status 
The business rules are updateable by the insurance carrier system 65. The 

assignee profiles, including status can be updated by the assignee, a systems 
administrator, or automatically periodically by the system 30. For example, status can be 
automatically retrieved from an assignee system when an assignee submits an estimate to 
the system 30. 

vi. Automation 

While the triage sub-system 220 and assignment sub-system 230 can fully 
automate the process of assigning claims according to insurance carrier business rules, 
these sub-systems can function at variable levels to provide variable levels of automation. 
For example, claims that score low can be fully automated, however when a claim 
receives a score above a certain threshold or a particular class is assigned to the claim by 
the triage sub-system 220, a human participant such as an insurance adjuster may be 
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notified and passed the task of determine and making the final assignments. In an 
example where a human participant such as an insurance adjuster ultimately decides 
which assignee to assign a claim to, the triage sub-systems 220 may still score and class 
the claim to provide the adjustor with a processed score and class of the claim which can 
serve as an automated reference point, as well as suggested types of assignees to assign 
the claim to. The assignment sub-system 230 would apply the business rules to provide a 
list of suggested assignees that fit a certain profile and have sufficient capacity to process 
the assignment, while the adjuster could then choose to pick from the suggested list or 
choose an assignee that has not been pre-selected by the assignment sub-system 230. 

FIG. 12A is a screen shot of a list of claims that a human participant needs to 
assign. FIG. 12B is a screen shot of the details of a claim. FIG. 12C is a screen shot of 
an assignee search function that is driven by user-selected criteria. FIG. 1 2D is a screen 
shot of a list of potential assignees. FIG. 12E is a screen shot of a potential assignee's 
details. FIG 12F is a screen shot of a record of assignment. FIG. 12A-F demonstrates 
how, in one embodiment, the triage and assignment process is lightly automated. 

FIG. 15 is a business object model for an assignment sub-system 230. This BOM 
provides an explanation of and relationship between the objects used in a preferred 
implementation of the invention. 

4. Vendor Connection and Assignment Management System (Connection): 
a. General 

The vendor connection and assignment management system (Connection) 300 is 
an open (i.e., able to communicate with various systems, e.g., insurance carrier systems 
65, estimate systems, and system 30 sub-systems, over a non-proprietary format and 
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communication medium) claim related task management, and claim data management 
and communication system designed for utilization by vendors, particularly repair 
facilities, independent appraisers and insurance carriers. 

Connection 300 retrieves claim data, which can be related to an assignment, 
manages and is able to transmit claim data, which can be repair related, and estimate 
information to vendors (e.g., repair facilities and independent adjusters), insurance carrier 
systems 65, suppliers of parts and materials, vehicle owners, and to the eclaim database 
280. 

b. Functionality of the Connection System 
Each of the functions of Connection 300 described below can operate in 
conjunction with the rest of the functions described below or independently. 

i. Receipt and Management of Claim Data 
A user can utilize Connection 300 to receive and process claim data from an 
insurance carrier system 65 or the system 30. In one embodiment, Connection 300 
retrieves data from the eclaim database 280 in response to a notification of an assignment 
from the assignment sub-system 230. The claim data retrieved can be stored locally on 
the user computer 2 or other I/O device 1 . Connection 300 then allows a user to view and 
manage the claim data in various presentation formats. For example, FIG. 16 is a screen 
shot of a main screen of an implementation of the Connection 300 system, which is 
exemplary of a data format that Connection 300 can present claim data to a user. In the 
screen shot of FIG. 16, assignments outstanding are presented to the user. In addition to 
administrative claim data (e.g., an assignment's claim number, date of loss, and claimant 
information management), Connection 300 allows the user to view already attached 
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digital images (e.g., digital photographs, and scanned images) or other digital formatted 
documents. FIG. 17 is a screen shot of a digital photo displayed by Connection 300. In 
one embodiment, Connection 300 can retrieves reports, which may be generated by the 
reporting sub-system 270, and stored in the directory database 290. 

ii. Adding Data 

In addition to being able to view initial claim data associated with an assignment, 
Connection 300 allows the user to append additional information such as digital images 
to initial claim data. Digital photos, and scanned images of, for example, photographs, 
and documents such as tow bills, parts invoices and police reports can be associated with 
the initial claim data. Connection 300 supports digital images from any commercially 
available digital camera or TWAIN-compliant scanner. In one embodiment, Connection 
300 allows the user to print electronic documents to a print driver sub-component of 
Connection 300, which will attach a digital image of the document to the inbox for that 
claim. Digital images retrieved or added through Connection 300 are watermarked for 
protection such that any alteration of the image will negate the watermark. 

iii. Editing Claim Data 

Initial claim data and data added to the initial claim data can be viewed and edited 
through Connection 300. In addition to enabling the user to edit stored digital text, 
Connection 300 can be used to rotate, crop, enlarge, invert and enhance digital images. 

iv. Communication with Estimating Systems 
Connection 300 transmits claim data to estimating systems (e.g., Comp-Est, 

Shoplink, Ultramate, and Pathways) and can retrieve and add detailed estimates provided 
from estimating systems to claim data. From estimate data retrieved from an estimating 
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system, Connection 300 can create an electronic quote request for specific parts and types 
of parts (e.g., OEM, salvage, aftermarket, or glass) and transmit that request to an 
appropriate vendor. 

v. Claims Folder 

In one embodiment, initial claim data and subsequent edits of the initial claim 
data added to the initial claim data are associated and stored in a fashion that all data 
relating to a certain assignment can be easily retrieved. The relational storage and 
retrieval of claim data associated with a single assignment or claim can be envisioned as 
the creation of a claim folder for each assignment or claim. 

vi. Transmission of Claim Data in an Open format and through 
Open Communication standards. 

Connection 300 stores received, added and edited data, including digital images, 
in an open format that is readable by various estimating systems and insurance carrier 
systems 65. In addition, Connection 300 transmits claim data to insurance carriers, parts 
and materials vendors, vehicle owners and other parties involved in the claims process 
through open (non-proprietary) communication standards (i.e., standard Internet 
protocols) that allow parties, including proprietary and legacy systems to receive the data. 
In one embodiment, Connection 300 communicates with other parties involved in the 
claims process through the communication network 25. 

Connection 300 can communicate to parties indirectly, through posting data to a 
website or transmission of the data to the eclaim database 280 coupled with notification 
to the intended receiving party that the data is stored on a website or the eclaim database 
280 along with sufficient reference and authorization information, if necessary, that the 
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party is able to locate and retrieve the data. For example, a repair facility can utilize 
Connection 300 to periodically post repair status and expected date of completion 
information or other claim information (e.g., administrative information, or 
status/capacity to fill additional assignments) to a website or the eclaim database 280, 
then can notify a vehicle owner that the vehicle owner can retrieve repair status or other 
data relating to their vehicle from the website or the eclaim database 280. The vehicle 
owner will no longer need to directly contact the repair facility to determine the status of 
the repair. 

5. Audit sub-system 
a. General 

The audit sub-system 240 periodically reviews stored claim data applies insurance 
carrier established and editable business rules to determine if any pieces of claim data do 
not meet the criteria set by the business rules. If any pieces of claim data do not meet 
insurance carrier criteria, the audit sub-system 240 can automatically direct an action set 
by the business rules to resolve the violation, or notify a human participant such as an 
insurance carrier adjuster, of the failure. The audit sub-system 240 is able to detect and 
direct resolution of claim processing that was incorrect, processes that need to be 
conducted but were not, unreasonable estimates, and potentially fraudulent transactions. 

As audit sub-system 240 finds situations that match the rules established by a 
particular insurance carrier, it will act upon those findings accordingly. According to 
certain business rules, the audit sub-system 240 can remove claims from the automated 
process and refer them back to the insurance carrier for personal attention or could 
continue through the automated process with notification going back to the carrier for 
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informative purposes. The audit process could be a matter of finding certain flags, 
running the information past another database and then, based on those findings, either 
continuing on with the process or referring it back to the insurance carrier. The audit sub- 
system 240 could also be set to notify a carrier whenever certain trends are detected. For 
example, if a certain repair facility's average cost per estimate had increased more than a 
certain % in a certain amount a time, a notification could be sent to the carrier for them to 
further investigate the causes. Again, the audit sub-system 240 looks for exceptions to 
the standard, accepted procedures or practices that the insurance carrier has established in 
the form of business rules. 

b. Process 

FIG. 18 is a flow diagram of an audit process. The audit sub-system 240 retrieves 
1801 claim data from the eclaim database 280, the insurance carrier system 65 or vendor 
systems 75 at variable instances set according to business rules. For example, a business 
rule may be that after each submission and capture of a new claim, the claim data must be 
audited by the audit sub-system 240. In another example, a business rule requires the 
audit sub-system 240 to review and audit each estimate submitted by a vendor. In one 
embodiment, the audit sub-system 240 and the automated audit process can be initiated 
by a human participant such as a insurance carrier appraiser after a certain amount of 
human auditing has already taken place. In one embodiment, claim data can be sent 
directly to the audit sub-system 240 directly. 

i. Business rules and Statutory Regulations 
The audit sub-system 240 processes 1803 retrieved or received claim related data 
according to business rules designated by an insurance carrier. Business rules are 
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editable and updateable at the direction of the insurance carrier. Through application of 
insurance carrier business rules to the claims data, the audit sub-system 240 determines 
1 805 if any business rules are violated. For example, if a business rule is that only used 
parts should be used to the repair vehicles made in 1995 or earlier, and an estimate 
submitted by a repair facility references to use of new parts for repair of a 1990 vehicle, 
the audit sub-system 240 would automatically detect that the repair facility's estimate had 
violated a business rule. 

In one embodiment, the audit sub-system 240 determines if statutory regulations 
are satisfied in the processing of the claim thus far. The audit sub-system 240 applies 
statutory regulations to claim data in a similar fashion to the application of insurance 
carrier business rules. For example, certain state regulations mandate that certain 
notifications need to be sent to consumers, while another imposes cycle time limitations 
on addressing a filed claim. The audit sub-system 240 determines if notifications have 
been sent and automates the process of sending the notifications if they have not been 
sent. Also, in the case of statutory regulated deadlines, the audit sub-system 240 
generates reminders to responsible parties that a task must be completed by a mandated 
deadline. The audit sub-system 240 is provided a list of statutory regulations that apply 
to the claim process the audit sub-system 240 is auditing. Statutory regulations can be 
edited and updated to reflect changes in the law. 

ii. Violations 

If no business rule or statutory regulation has been violated, the audit process 
terminates 1809. If a business rule or statutory regulation violation is detected, the audit 
sub-system 240 applies business rules to process the violation. The audit sub-system 240 
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can directly notify third parties involved (e.g., vendors or policy holders) of the violation 
with explanation as to reason for violation and proposed courses of action. For example, 
if an estimate submitted by a repair facility provides insufficient or invalid information, 
the audit sub-system 240 would detect the violation and notify the repair facility to 
complete or provide additional valid information. Violations resolution is governed by 
business rules and can require that the audit sub-system 240 notify and transfer the audit 
process to a human participant such as an insurance carrier appraiser. For example, if 
instead of determining that an estimate submitted by a repair facility violates business 
rules by failing to submit sufficient or valid information, the audit sub-system 240 
determines that the estimate contains sufficient and valid information, but is unreasonably 
high, the audit sub-system 240 would assign the audit process to an human participant 
such as an insurance carrier adjuster to conduct an additional audit, and if the estimate is 
still found unreasonable, to negotiate with the repair facility to change the estimate. In an 
alternate embodiment, in the previous example, the audit sub-system 240 could 
automatically notify the repair facility that their estimate was denied, that it was 
unreasonable, and with sufficient details of denial such that the repair facility can attempt 
to make a more reasonable estimate. 

In another example, audit sub-system 240 determined potential cases of fraud, 
through application of business rules, would be transferred to a special investigating unit 
for further processing. In one embodiment, fraud detection is determined by a fraud 
detection system separate from the audit sub-system 240. 

iii. Trending Analysis 
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In one embodiment, the audit sub-system 240 applies trending analysis to claim 
data to determine if the claim data falls outside of normal boundaries. For example, 
instead or in addition to applying a business rule that lists circumstances (e.g., the cost of 
a hood is within a certain range) in estimates that would result in the estimate being 
determined unreasonable, the audit sub-system 240 can apply trending analysis data that 
can be stored in the eclaim database 280 or generated by the reporting sub-system 270. 
For example, the reporting sub-system could determine how much the last 100 repair 
facilities charged for the repair of the left front door of a specific vehicle make, model 
and year. If claim data of a newly submit estimate for a comparable task is retrieved by 
the audit sub-system 240, the audit sub-system 240 applies the report to determine if the 
estimate is unreasonable for falling outside of the ranges. 

iv. Notification of Audit Findings and Logging the Audit 

Upon termination of the audit process, either through no violation of business 
rules or statutory regulations being found, or if a violation was found, the audit sub- 
system 240 rectifying the violation according to business rules, the audit sub-system 240 
notifies the sub-system or systems that it operates directly in conjunction with (e.g., the 
eclaim database 280 and the insurance carrier system 65) of the result of the audit process 
and logs an entry of the decision and details related to the decision to those system(s). In 
one embodiment, the audit sub-system 240 notifies a third party (e.g., a vendor or a 
policy holder or consumer) that does not interact directly with the audit sub-system 240 
of the audit sub-system 240s conclusion. For example, if the audit sub-system 240 audits 
an estimate submitted by a repair facility and determines does not approve the estimate, 
the audit sub-system 240 notifies the repair facility that the estimate was denied. 
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6. Electronic Claim File Repository (eclaim database) 
a. General 

FIG. 19 is a block diagram of the systems and sub-systems that transmit, store, or 
retrieve claim data, from an electron claim file repository. The electronic claim file 
repository (eclaim database) 280 is a central relational database where claim related and 
transactional data is received, stored and exists to be accessed by systems and sub- 
systems. Claim data stored in the eclaim file is in an open data format that is readable by 
various sub-systems and systems. Any number of systems or sub-systems, ranging from 
one to all of the systems and sub-systems that interact with system 30, are able to 
interface with the eclaim database 280. 

Claim data, including administrative information related to insurance policies, 
policy holders (such as name, address, policy information, and transactions), consumers, 
and other users (e.g., insurance carriers, and vendors), as well as assignments, estimates, 
digital images, supplements, status of tasks related to the claim, transaction logs and 
entries, parts lists, warranties, payment information, and reports is stored in the eclaim 
database 280. In one embodiment, instead of storing detailed vendor related 
administrative and other data (e.g., CSI) in the eclaim database 280, detailed vendor 
related claim data is stored in the directory database 290 which is linked to general 
vendor claim data that is stored on the eclaim database 280. Certain claim data is stored 
in a format that cannot be edited based on governmental regulatory requirements or due 
to business rules. For example, initial claim data captured by FNOL 210 or receiving and 
stored in the eclaim database 280 from insurance carrier systems 65 are frozen so as to 
prevent fraud. In another example, digital scanned images of legal documents are stored 
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in an uneditable format. However, in one embodiment, copies of this data, which are 
labeled as copies and not originals, are made and can be edited or manipulated and added 
to the virtual claim file containing the original data. 

In one embodiment, claim data is associated and stored in a fashion that all data 
relating to a certain claim can be easily retrieved. The relational storage and retrieval of 
claim data associated with a single claim can be envisioned as the creation of virtual 
claim folders or files for each claim. In one embodiment, a unique claim number, usually 
represented by an alphanumeric data field, is assigned to each claim that is stored in the 
eclaim database 280. All pieces of claim data related to that claim are marked with the 
unique claim number and can thus be associated with other claim data related to the 
single claim. Furthermore, the data elements that make up a claim can be grouped into 
claim segments within the overall claim through the assignment of an unique identifier 
that is attached to all claim data of the claim segment. These claim segments (suffixes) 
could represent a particular coverage type, claimant, vehicle or individual associated to a 
particular claim. 

In one embodiment, the eclaim database 280 is segregated into segments 
designated to store claim data related to a specific insurance carrier. 

Access to the eclaim database 280 is governed by the user authentication sub- 
system 211, with various parties having variable degrees or levels of access to claim data 
stored on the eclaim database 280. 

The eclaim database 280 can be regularly updated through a feed of data received 
from the systems or sub-systems that interact with it. In one embodiment, the eclaim 
database 280 imports or pulls claim related data from systems or sub-systems. The 
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eclaim database 280 receives automated data imports (e.g., status data of work related to 
a claim) from other systems and sub-systems. 

FIG. 20 is a business object model for the eclaim database 280, which outlines the 
relationship between claim related data stored in the eclaim database 280. FIG. 21 is a 
business object model, which outlines the relationship between an insurance carrier or 
vendor and the data attributes and elements associated to it that are stored in the eclaim 
database 280. FIG. 22 is a business object model, which is linked to the business object 
models of FIG. 20 and FIG. 21, and outlines the user roles and relationships to data 
described in the business object models of FIG. 20 and FIG. 21 

7. User Interface and Claim Manager Sub-system (Deskview) 

a. General 

FIG. 23 is a block diagram of the systems, sub-systems and database that interface 
with a user interface and claim manager sub-system. The user interface and claim 
manager sub-system (Deskview) 200 is a user interface and claim management system, 
which interfaces with and can be utilized to access, view, edit, and add claim data stored 
in the eclaim database 280. Deskview 200 also acts as a portal point from which other 
sub-systems of system 30 can be accessed and utilized. 

b. Features 

i. Retrieve, View, Edit, and Add Claim Data 
FIG. 24A is a screenshot of a user interface and claim management system 
viewing and editing claim data feature. Deskview 200 allows a user to search for and 
view claim data associated with a single claim, the claim data being linked and 
retrievable such that the user is presented with an integrated virtual claim file of claim 



58 



22606/05796/DOCS/l 159542.4 



data associated with a claim. Claim data can be presented to a user through Deskview 
200 in a general, high-level, summary format as well as various degrees of more detailed 
formats to allow the user to decide what degree to drill down into the details of a claim. 
In one embodiment, Deskview 200 also provides an interface with the directory database 
290. 

Claim data accessible via Deskview 200 include the severity of claims, vehicle 
damage, cycle time for claim processing, repair status updates, estimates, basic 
management reports, attached digital images, and transaction logs. Examples of filters, 
which can be used individually or in combination to present claim files in an organize 
format include region, company, claim office, date claim received/reported. Examples of 
search criteria, which can be used individually or in combination to retrieve specific 
claims, include claim number, policy number, claimant name, insured name, data of loss, 
and adjuster ID. In one embodiment, claim data related to a claim is automatically 
presented to the user upon entry to Deskview 200 according to business rules. For 
example, an adjuster may be automatically presented with all the claims that assigned to 
him for review and processing upon accessing Deskview 200. 

In addition, Deskview 200 allows the user to change or edit or manipulate claim 
data such as administrative information and digital images to the virtual claim file. FIG. 
24B is a screenshot of a user interface and claim management system viewing and editing 
digital images feature. Claim data such as administrative information and digital images 
can be appended to the virtual claim file as well. For example, a user utilizing Deskview 
200 can enter notes concerning the claim or link emails and other documents to the other 
claim related data that compose a virtual claim file. Certain claim data is stored in a 
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format that cannot be edited based on governmental regulatory requirements or due to 
business rules. For example, initial claim data captured by FNOL 2 1 0 or receiving and 
stored in the eclaim database 280 from insurance carrier systems 65 are frozen so as to 
prevent fraud. However, in one embodiment, copies of this data, which are labeled as 
copies and not originals, are made and can be edited or manipulated and added to the 
virtual claim file containing the original data. 

In one embodiment, claim data stored, for example status or capacity of a given 
vendor to fulfill an assignment, in the directory database 290 can be accessed, edited and 
added to using Deskview 200. In one embodiment, claim data stored eclaim database 
290 links to more detailed claim data stored in the directory database 290. For example, 
a vendor's general information can be stored on the eclaim database 280, while more 
detailed vendor administrative information stored on the directory database 290 is linked 
to the general data. In another embodiment, claim data stored in insurance carrier 
systems 65 can be accessed, edited and added to using Deskview 200. 

Access and the degree to which a user can view, edit, or add to claim data stored 
in the eclaim file 280 is governed by the authentication sub-system 215. Deskview 200 
utilizes the data relationships outlined in the business object models of FIG. 20, 21, 22 to 
display, edit, or add claim data to claim data stored in the eclaim database 280 and the 
directory database 290. 

ii. Portal, Navigation Point 

FIG. 25 is a screenshot of a user interface and claim management system 
navigation feature. Deskview 200 is also the point at which a users log into the system 
30, and can navigate to other sub-systems of the system 30 through use of links or 
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buttons. Which sub-systems a user is able to access via Deskview 200 is governed by the 
authentication sub-system 215. The navigation buttons or links presented to a user 
through Deskview 200 are consistent with the sub-systems the user is able to access. In 
an example of the utilization of the navigation feature of Deskview 200, a user such as an 
insurance adjuster may enter the system 30 through Deskview 200, have claims assigned 
to automatically presented upon entering Deskview 200, view the claim in detail, then 
decide what function needs to be performed on the claim, e.g., triage and assignment, 
audit, or payment. The user could then select the function, through utilization of 
navigation buttons, he wishes to process the claim with and be transferred to the sub- 
system or system that governs the selected process. As a specific example, a user may 
wish to determine a repair facility's cycle time and rate at which they convert an 
assignment into an estimate before assigning the claim. The user can access the reports 
sub-system 270 through use of the navigation buttons stored on Deskview 200, then 
directly utilize the reports sub-system to generate the desired report or reports. 
8. Automated Payment System: 
a. General 

FIG. 26 is a block diagram of the participants in an automated payment process. 
The circled numbers represents the order in which the process flows in the described 
embodiment. 

The Automated Payment System 250 (APS) automates the process of fulfilling 
payment requests made under insurance claims. APS 250 receives invoices (payment 
requests) from vendors, automatically approves payments according to the insurance 
carrier business rules, disburses payments to vendors via a trustee bank 2603 using ACH 
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(Automated Clearing House) methods, where possible, tracks the transaction, and 
provides reconciliation and accounting details to the Insurance Carrier systems. For 
automobile line of insurance, examples of vendors who provide invoices and receive 
payment are Repair Facilities, Independent Appraisers, Rental Agencies, Towing 
Facilities, Salvage Companies, Storage Facilities, and Parts Suppliers, Auto Glass 
Suppliers, and even policy holders or claimants who have incurred pre-paid costs covered 
under the insurance policy. For the movement of funds, the insurance carrier's bank 2601 
will fund the trustee bank's 2603 escrow account; and the trustee bank 2603 will pay the 
payee 2605 or fund the vendor's (payee) bank. 

The APS 250 receives an invoice or estimate directly from the vendor in 
electronic form, automatically approves payments based on the carrier's payment rules, 
aggregate payments for vendors, automatically disburses payments via the claims 
payment clearing house in the form of the trustee bank 2603, and automatically 
reconciles the loss and the payment to the carrier's internal systems. 

The APS 250 will also support customer service for carrier and vendor queries, 
b. Process 

FIG. 27 is a flow diagram of a process of automating claim payments from the 
prospective of an automated processing system. First, the APS 250 receives 2701 an 
electronic payment request based on a fee estimate or an invoice for work already 
completed. In one embodiment, the electronic payment request contains: (1) information 
about the insurance claim the request is being made under, (2) the requestor's profile 
information (e.g., name, address, phone number, email address, payment preference (e.g., 
ACH, wire transfer, check), ACH data, if any.), and (3) information about the request 
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being made including work done, or to be done, amounts requested for tasks completed 
or on amounts requested based on estimated cost for tasks to be completed. 

In an alternate embodiment, the payment request will have sufficient reference 
information to allow the APS 250 to retrieve information such as details of the claim the 
request is being made under and the requestor's profile information from the eclaim 
database 280, directory database 290, or insurance claim system 65. For example, the 
electronic payment request might have an eclaim database 280 user identification and 
password, along with an identification number that represents the claim. These 
identification numbers that will allow the APS 250 to access the eclaim database 280 and 
retrieve claim data for the particular claim the request is being made under. In one 
embodiment, a progress payment request can be made for a partially completed task. 

In one embodiment, once the payment request is received, APS notifies the eclaim 
database 280 and the insurance carrier system 65 of the request for payment and 
periodically updates the database and system with the payment status of the request. 

Next, the APS 250 determines 2703 if the payment request is being made under a 
valid insurance policy. In one embodiment, policy information can be stored and 
retrieved from the eclaim database 280. In another embodiment, policy information is 
stored on the insurance carrier system 65. 

Once the insurance policy is validated, the APS 250 validates 2705 the payee by 
determining if the payee 2605 profile information is stored in the directory database 290. 
If the payee 2605 profile information is not stored in the directory database 290, the APS 
250 adds the payee 2605 profile information provided in the payment request to the 
directory database 290. Insufficient profile information will cause the APS 250 to notify 



63 



22606/05796/DOCS/l 1 59542.4 



the payee 2605 to complete the information. After a set number of notifications to the 
payee 2605 of insufficient profile information have not produced a complete set of profile 
information the APS 250 will notify the payee 2605 contact the insurance carrier after a. 
i. Validating a Payment Request 
Next, the APS 250 validates 2707 the payment request by applying the insurance 
carrier specific business rules to the payment request. For example, a business rule may 
be that Direct Repair Program (DRP) members are entitled to pre-approval status for 
claims under $500. The APS 250 would then retrieve insurance carrier vendor (payee 
2605) profiles, which are setup and maintained on the directory database 290 and 
determine if the vendor, e.g., a repair shop, is a DRP member. If the vendor is 
determined to be a DRP member and the claim is under $500, the APS 250 would 
automatically approve the repair payment, without any intervention from a Claims 
Adjuster. 

In the case of progress payment requests, the APS 250 can determine based on the 
insurance carrier's business rules if the request matches a progress milestone or fulfills 
some other criteria. In one embodiment, progress payments may be processed 
automatically without requiring the payee 2605 to make a payment request. For example, 
a business rule may allow APS to automatically pay a DRP member whose has a fast 
average cycle time of repairs a portion of repair fees proportionate to the time since the 
assignment was made and the current date. For example a DRP who has shown, on 
average, that a certain task assigned to it requires ten days for the to complete, would be 
paid 50% of the estimated repair fees five days after the assignment was made. 
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In one embodiment, if a payment request is not approved by the Insurance Carrier 
business rules, the APS 250 can direct the requesting party to resubmit the request or 
contact an insurance carrier representative. In alternate embodiment, for payment 
requests that are not approved by the APS 250 through application of the insurance 
carrier business rules, the APS 250 notifies Insurance Carrier personnel to intervene and 
manually approve invoices not adhering to Insurance Carrier's pre-defined business rules. 
In another embodiment, instead of applying the insurance carrier specific business rules 
to the invoice information directly, the APS 250 directs the received invoice to the audit 
sub-system 260, described above and in more detail below, for validation and approval. 

In one embodiment, once the APS approves a payment request to pay an invoice 
for certain work completed (e.g., automobile repair), the APS requires confirmation of 
satisfaction from the policy holder or consumer who made the claim. Confirmation can 
be received in many forms. In one embodiment, the policy holder or consumer utilizes 
an I/O device 1 at the vendor site upon review of the services. For example, a policy 
holder could be proved with a dial-in phone number which will prompt the policy holder 
through a confirmation authorization process. In another example, the policy holder uses 
the vendor's computer 2 to log onto a website and confirm that the policy holder is 
satisfied. 

ii. Funding Request Sent 
Once the APS 250 approves a payment requests and for certain circumstances, 
receives 2709 confirmation of satisfaction, APS notifies the insurance carrier system 65 
to authorize the insurance carrier bank 2601 to fund the trustee bank. In one embodiment 
APS 250 accumulates the insurance carrier's approved payments in a queue until the 
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scheduled payment date. On or before the payment date, the APS 250 aggregates all 
approved payments for each payee 2605 within carrier. APS creates a aggregate or 
bundled funding request and transmits the funding request to the insurance carrier system 
65. In another embodiment, APS transmits a funding request to the insurance carrier 
system 65 for each approved payment request. 

Payment information, which includes the payee's profile (e.g., name, address, 
email address, phone number, and ACH information, if the payee 2605 is to be paid via 
ACH), amount of to be paid, and payment execution date are transmitted to trustee bank 
2603 and the Insurance Carrier's Claims and Accounting systems within the Insurance 
Carrier system 65. 

iii. Insurance Carrier Bank funds Trustee Bank Escrow 
Account 

After the insurance carrier receives the funding request, it directs its bank 2601 to 
transfer an amount equal to the total funding request to the trustee bank. In one 
embodiment, the carrier's bank transfers the necessary funds through a wire transfer or 
through ACH on the day the funding request is transmitted from the APS 250 to the 
Insurance Carrier's bank. In an alternate embodiment, funding requests can be made 
prior to the payment date, and funds can be transferred to the trustee bank 2603 before 
the payment date. 

APS 250 requests policy holder or consumer to recognize the assignment has been 
fulfilled. 

iv. Clearing House receives Payment execution order from 
APS 
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APS 250, based on insurance carrier business rules, determines payment 
execution dates. The APS 250 directs 2713 the trustee bank 2603 to execute a single or 
batch of payments to fulfill a single or multiple payment requests on the payment 
execution date, which can be the same date APS places to order to execute or can be a 
date different from the date APS places to order to execute. The trustee bank 2603 
executes orders that it has previously received payment information for, and for which 
the trustee bank 2603 has received sufficient funds to cover the disbursement from the 
insurance carrier bank 2601 prior to the payment execution date of the order. In another 
embodiment, if the trustee bank 2603 does not receive funds matching the execution 
amount, the trustee bank 2603 may still execute payment execution orders based on 
previously received funds that are sufficient to cover the disbursement or through 
drawing down on an insurance carrier's line of credit, which is not, nor will be overdrawn 
by the execution of the payment(s), with the trustee bank 2603, if an insurance carrier has 
such a line of credit with the trustee bank 2603. 

v. Payment Execution 

Next, payments, individual or aggregated, are made to each payee 2605 via ACH, 
wire, or check from the trustee bank 2603 on the established payment date. In an 
alternate embodiment, payments are made in the form of authorization information to 
directly debit an insurance carrier bank account for the amount owed the payee (e.g., a 
credit card number with which the payee can debit the amount owed). In one 
embodiment, the insurance carrier system 65 is enabled to view account status of the 
bank account open for payees to draw on and audit the debits to the account. In one 
embodiment, the insurance carrier views the account status over the Internet. This audit 
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feature allows the insurance carrier to detect inaccuracies in debits, particularly debits of 
amounts in access of those authorized. 

vi. Reporting 

The trustee bank 2603 provides electronic notification to the APS 250 that 
payment has been made to the payees 2605. APS notifies 2715 the payee 2605 that 
payment has been executed. Once the payments have been made and the payees 2605 
have been notified, the APS 250 updates 2715 the eclaim database 280 with the details of 
the payment. In another embodiment, once the payments have been made and the payee 
2605s have been notified, the insurance carrier system 65 is updated with payment details 
to reflect the payment. In one embodiment, an entry of the payment is logged in the 
transaction record stored of the eclaim database 280. 

vii. Account Structure of the Trustee Bank 

In one embodiment, the account structure of the trustee bank 2603 will be an 
omnibus escrow account where each carrier's funds are tracked via sub-accounting. The 
trustee bank 2603 maintains custody of funds until disbursement and provides payment 
support services (customer service). In an alternate embodiment, each insurance carrier 
would open a separate escrow account within the clearinghouse. 

viii. Payment Aggregation by the Clearing House 

In one embodiment, an individual payment is sent to a payee 2605 for each 
payment request made and validated. In an alternate embodiment, payments to payees 
2605s with multiple payment requests that are validated are aggregated into a single 
payment. In one embodiment, multiple payments from a single insurance carrier to a 
single payee 2605 are aggregated into a single payment. In an alternate embodiment, 
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payments to the same payee 2605 are aggregated across all carriers participating in the 
clearing house. Individual payee 2605s are uniquely identified by a payee 2605 code. In 
yet another embodiment, the APS 250 aggregates payments at both levels: multiple 
payments from a single carrier to a single payee 2605 , and payments from several carriers 
to a single payee 2605 are aggregated into one payment. 

ix. Payee/Payor Inquiry to Clearing House 

In one embodiment, the trustee bank will provide customer service via the 
telephone. Payees 2605 or payors who have questions regarding lost, destroyed checks 
can contact a 1 800 number for customer service. Additionally, customers who have 
question regarding ACH payments can contact the customer service number as well. The 
clearinghouse will only answer questions regarding payments it has executed based on 
the APS 250 instructions. Any questions regarding claims, invoice amounts, etc will be 
directed to the APS 250 system or the specific Insurance Carrier (Payor). 

x. Reconciliation 

In one embodiment, APS 250 tracks payments by insurance carrier, claim 
number, payee 2605 and amount. For aggregated payments, sufficient individualized 
information is provided the payee 2605 such that the aggregate payments can be 
decomposed into claim-level or job-specific detail. In another embodiment, after an 
aggregate payment has been made and APS 250 transmits notification of the payment to 
the payee 2605, APS 250 provides the payee 2605 with sufficient information to access, 
view and retrieve payment data stored on the eclaim database 280 to allow the payee to 
decompose the aggregate payment. 



69 



22606/05796/DOCS/l 1 59542.4 



APS 250 provides information to the insurance carrier system 65 to allow the 
claim and accounting information systems of the insurance system 65 to ensure the 
payments balance, close the claim, and update the insurance carrier database. In an 
alternate embodiment, the insurance carrier system 65 is provided access to and retrieval 
information to retrieve payment information from the eclaim database 180. 

9. The Customer Satisfaction Index Collection Sub-System (CSI sub-system) 

a. General 

CSI sub-system 260 generates questionnaires to gather customer satisfaction data 
from customers (e.g., policy holders or consumers), gathers the customer satisfaction 
data, and then use the data gathered to generate a customer satisfaction index (CSI) score 
for each survey and an aggregate CSI score from the individual CSI scores for each 
commercial participant (e.g., service providers, insurance carrier staff who have handled 
a policy holder claim, the insurance carrier.) which can be stored and later utilized in 
ranking the commercial participant. In one embodiment, data of user satisfaction of 
processes, sub-systems and systems described above is also gathered. The survey data 
gathered from policy holders and consumers are stored in the eclaim database 280, while 
the calculated aggregate CSI is stored into the directory database 290 in association with 
the party whose work is being scored. In one embodiment, incentives such as discounts 
on repairs are provided to customers to retrieve satisfaction data from them. 

b. Process 

i. Generation of a Customer Service Questionnaire 
The CSI sub-system generates general customer service questionnaires that stored 
on the eclaim database 280. Questionnaires include both structured questions with 
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predefined possible answers including multiple choice answers and unstructured 
questions to be answered using free text. Commercial participant can add ad-hoc 
questions to the standard survey questions. 

ii. Gathering Customer Satisfaction Data 

The CSI sub-system directs gathering of customer satisfaction data in a number of 
methods. First, when claim services are completed, the consumer completes the 
consumer satisfaction survey via a client software 205 interface or a voice based interface 
207. Preferably, the consumer uses his or her I/O Device 1 to review the customer 
satisfaction survey questions stored in the eclaim database 280. In another embodiment, 
the CSI sub-system emails customers a message asking them to provide feedback. The 
email contains a hyperlink to a survey form located at a website. In another embodiment, 
the consumer completes a paper version of the survey and sends that to a data entry group 
that uses I/O devices 1 to forward the responses to the CSI sub-system for storage in the 
eclaim database 280. 

In another implementation, a call center is employed to contact customers directly 
with survey questions, the call center staff filling out the CSI survey questions as they are 
answered by the customer. The CSI sub-system can create interview scripts stored on the 
eclaim database 280 to be used by call center staff. The CSI sub-system can also 
generate calling lists from customer data stored on the eclaim database 280 or retrieves 
call lists stored on the eclaim database. In one embodiment, the CSI sub-system removes 
numbers from the call list based on transaction entry that shows that a particular customer 
had already completed the survey. In another embodiment, the CSI sub-system de- 
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duplicates phone numbers listed on the eclaim database to prevent the same number from 
being inadvertently called twice. 

hi. Generating a Customer Satisfaction Customer Satisfaction 
Data and Report Generation: 
The results of the consumer satisfaction surveys are retrieved from the eclaim 
database 280 compiled by the CSI sub-system. The CSI sub-system utilizes an algorithm 
to generate a composite index score for each survey. The CSI sub-system then updates 
the overall CSI index score for that service provider in an entry to industry directory 
database 290 incorporating the new result. The resulting overall CSI index for a given 
vendor can be displayed with the profile of the assignee the next time the service 
provider's data in industry directory database 290 is accessed from the system 30, 
particularly by the assignment sub-system 230. 

If a designated client receives a satisfaction score below a pre-defined threshold, 
the CSI sub-system automatically notifies the client of the low score according to client 
designated notification preferences. This automatic notification allows the client to 
determine the reason for the low score and attempt to rectify instances of low customer 
satisfactions or change methods that produce low customer satisfaction. 

The commercial participant can view their customer satisfaction data (e.g., stored 
answered surveys, individual CSI index scores generated for each survey, and aggregate 
CSI index score generated for the commercial participant) stored on the eclaim database 
280 or the directory database 290. In one embodiment, customer satisfaction data is 
added to the eclaim database 280 as soon as retrieved (which can be many times in a 
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day), thus, commercial participants can review customer satisfaction in a near real-time 
fashion. 

In addition, customer satisfaction reports can be generated by the reports sub- 
system 270 for the survey data. Reports can be generated daily, weekly, monthly, 
quarterly, and yearly reports on customer satisfaction and include reports that aggregate 
industry ratings for benchmarking (comparison with the performance of other 
commercial participants) and graphical reports. 

1 0. Reporting Sub-System 

a. General 

The reporting sub-system 270 summarizes and formats data stored in the eclaim 
database 280 or the insurance carrier system 65, based on a number of criteria, to 
generate various reports. Examples of reports generated by the reporting sub-system 270 
are cycle times, conversion ratios, and current assignments outstanding. In one 
embodiment, the reporting sub-system 270 generates reports from data stored in the 
directory database 290. The reporting sub-system 270 can generate upon request or pre- 
generate and store reports to be retrieved later. In one embodiment, once a report is 
generated it can be stored in the directory database 290, if specific to a vendor(s), or is 
stored in the eclaim database 280, if not specifically related to a vendor(s). 

The reporting sub-system analyzes stored claim data elements (e.g., severity of 
claims, vehicle damage), estimates, detailed estimate data, transaction logs and other key 
performance measures to produce an aggregate view of transactions (e.g., counts, 
averages, users, business units, geographical designations or average cycle times). 

b. Types of Reports 

i. Canned Reports 
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FIG. 28 is a screenshot of an example of canned or standard reports that a 
reporting sub-system can generate and a user can select. The reporting sub-system 
produces canned reports, reports whose criteria and data elements are pre-selected and 
static. A user can select from canned reports, but is unable to designate how the data of 
the report is presented. In one embodiment, the user can select the time frame (e.g., for 
the month of March, for the first quarter, for the year of 2001) of a canned report. 

Examples of canned or set operational reports generated from transaction logs 
data include the number of assignments made by adjuster per month, and the number of 
claims received by FNOL 210 per month. Examples of canned reports generated from 
transactional claim data include cycle time (calculated from the start and completion of a 
process), number of estimates, damage by vehicle type, average appraisal fee, OEM part 
usage. 

ii. Customized Reports 
In another embodiment, the reporting sub-system supports the generation of 
customized reports that match user selected criteria to produced focused results. The 
reporting sub-system is able generate reports indexed by activity within a specific time 
range, by activity within a geographical region, and by vehicle type. FIG. 29 is a 
screenshot of a report generated by a reporting sub-system that is indexed by region and 
by state within each region. In one embodiment, the reporting sub-system 270 allows a 
user to drill down and view the specific details of customized reports (e.g., the number of 
assignments can be presented in a per day, per adjuster per week, per month, per 
quarterly and per year format, or by adjuster, by service office, by region, and by 
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insurance carrier). In one embodiment, customized reports are generated by third party 
systems. 

Reports can be generated to analyze and compare trends in the processing of 
claims. For example, the average estimate for a certain type of repair over a current 
quarter, the month prior to the current quarter, the quarter prior to the current quarter, and 
the year prior to the current quarter. These trend-analyzing reports can provide an 
insurance carrier with data to determine if subsequent estimates for similar types of repair 
are reasonable or even potentially fraudulent. Reports can be generated real time at the 
point of request or at set times with the results being stored in the eclaim database 280, 
the directory database 290, or the insurance carrier system 65. 

FIG. 30 is a screen shot of date elements generated by a report sub-system 
exported to a Microsoft Excel software program. In one embodiment, the details of each 
report generated can be drilled down to and the reports as well as the details of each 
report can be exported to other systems (e.g., via email or through posting on a webpage). 
In one embodiment, data elements that compose the reports can be downloaded to 
Microsoft Access and Excel software. 

In a preferred embodiment, the data from originating database (i.e., the eclaim 
database 270, the directory database, or the insurance carrier system 65 database) that the 
reports are generated from is replicated and stored in a more efficient format for reporting 
analysis, and the reports are generated from that replicated mirror database so as not to 
burden the originating databases. 

It should be noted that at least one described embodiment operates in an 
automated fashion with no human intervention. Other embodiments may operate with 
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varying degrees of human intervention for, as an example, escalation of difficult claims 
or human estimation input. 

One example of a semi-automated process that employs sub-systems of the 

inventions: 

After FNOL 210 captures a new claim and stores the claim data in the eclaim 
database 280, the claim is automatically assigned by the triage and assignment sub- 
systems 220/230 to an insurance carrier adjuster. Once the assignments are made, the 
assignment sub-system 230 sends a notification message of the assignment via email to 
the adjuster and logs to the eclaim database 280 that the email was sent and the 
assignment was made. 

Next, when an insurance carrier adjuster logs on to the system 30 via Deskview 
200, he is first authenticated by the user authentication system 215. Next, a message 
appears on Deskview 200 displaying the number of new claims the adjuster has been 
assigned to further assign. The adjuster then uses Deskview 200 to view a queue 
containing their respective assignments, by way of Deskview's 200 search engine type 
functionality. Assignments are sorted by date displaying the most recent assignment first. 

The adjuster then selects the specific claim (or suffix) and searches the directory 
database 290 to find a vendor (e.g., class shop, independent appraisal and or staff 
adjuster) within a certain radius or other specific search criteria. The adjuster then selects 
the appropriate vendor and fills out a work request form. The work request form is pre- 
filled with data already collected and adjuster adds additional notes or instructions using 
Deskview 200. The work request form is sent via email, fax or other communication 
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methods to the vendors (assignees). The system 30 logs the transaction and updates the 
eClaim database 280. 

The vendors (assignees) acknowledge the receipt of the fax or email assignment via 
a fax back or reply email. If a fax was received, the adjuster could scan the fax and 
attach the digital image to the virtual claim file, which exists in the eclaim database 280 
for the particular claim. The system 30 can automatically log receipt of email to the 
eclaim 280. Internal assignees would be automatically updated once logged into the 
system and the claim or suffix is selected. Details of the assignment and claim data 
stored in the eclaim database 280 can be sent directly to the assignee. Alternatively, the 
assignee can retrieve claim data related to the assignment directly using Connection 300. 

Changes of status of work completed on the claim can be sent directly from a 
vendor to the system 30 via email or through Connection 300. Updates of status of work 
on the claim are logged by the system 30 to the eclaim database 280. 

It should also be noted that, in the described embodiment, most of the described 
subsystems are located centrally and accessed via the web or other network. Alternately, 
one or more subsystems could be located elsewhere, such as at a distributed site or could 
be accessed from a redirected web site, or an ASP web site. 



77 



22606/05796/DOCS/l 159542.4 



